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Editor's Desk 



By Chris IVIcEwen 



Don't You Love Euphemisms? 

These are lean times. You have heard that companies need 
to do more with less. This is a euphemism for giving more 
work to fewer people and aptly describes the office I occupy 
during my "other life." I spent the months of July through 
October out of town, with just a few weeks interspersed here 
and there.. 

This is both an explanation for my delay in getting this 
issue to you and its smaller size. 1 had grown fond of the 
sixty-four page format, enough so that I intend to return to it. 
But for now, we must suffice at forty-eight pages. We can 
hardly do more with fewer people; I am the entire 
production staff! 1 am back now, and things are returning to 
normal — or what passes for such in 
these parts.. Haa^^i^ii^^HaH 



ded control applications as vending machines have never 
been approached, what other markets has the Forth world 
ignored? 

There is an ongoing discussion over the Internet about 
Forth's saleability. Emotions run high over the value of ANSI 
standards, the lack of function libraries and incompatibilities 
between different Forth systems. Shucks, all this is meaning- 
less drivel if no one calls the client! 

Other Worlds 

1 have mentioned the Internet, Fidonet, GEnie and other 
forms of digital telecommuncations several times over the 

See Editor, page 26 



No One Called the Client 

I spent the last few months working 
on everything but computers — at least 
what the world thinks of as computers. 
I spent a week at the National Auto- 
matic Merchants' Association trade 
show in Chicago in early October. 
That's vending machines, nickel-rob- 
bers for the uninitiated. These days, the 
machines will gladly relieve you of 
your dollar bills. Five-spot robbers are 
just around the corner. 

In looking at the new wonders of 
the vending machine world, I found 
myself speaking to the vice president 
of engineering of a leading manufac- 
turer. Curiosity got the best of me and I 
had to ask, "What processor do you 
use to control these things?" The an- 
swer was no surprise: Motorola 
68HCll's. And what do they program 
in? "C, of course," 

Of course. 

Here we have folks producing 
equipment that is made-to-order for 
Forth and they are using C. This is not 
unusual. You hear it everyday. But the 
reason Forth was not considered 
floored me. A Forth vendor had never 
approached them, and they had no 
idea what it could offer. 

If manufacturers of classic embed- 



Reader-to-Reader 



I have a suggestion. To help me lo- 
cate the proper issue number when the 
TCJ's are in a bookshelf, I've taken to 
marking the issue number on the spine 
in quite large numbers centered 3 1/2" 
from the top. The orientation is side- 
ways (if the issue was lying flat on the 
table with the spine toward you, front 
cover up, the issue number would be 
right side up). The digits are about 3/ 
8" high and, since they wrap around 
both sides of the spine, they visually 
reduce to an apparent and still read- 
able 3/16" high or so. You might con- 
sider adding an issue number to your 
cover in a similar format for easier ref- 
erence. 

T.H. Los Gatos, CA 

Most magazines employ "perfect bind- 
ing" where the pages are glued to a 
backplane to accomplish what you want. I 
decided against this for two reasons: the 



pages will not lay flat with the book open, 
making it more difficult to copy listings 
and the binding cost is much higher. TCJ 
is a hold-out in publishing source code, 
and we run on a very tight budget, so per- 
fect binding was ruled out. — Ed. 



I am a long-distance member of 
Morrow Atlanta Users Group and re- 
ceive their Mor- Atlanta News, where I 
read your introduction to TCJ. I am 
not sure if your "free issue" offer will 
extend to chaps like me sitting under 
palm trees in the South Pacific! I have 
enclosed my last remaining US $1.00 
note to cover reply postage. 
P.D., Rotorua New Zealand 
/ spent your dollar at the post office 
mailing off your first copy for a trial sub- 
scription. When you get the invoice, just 
deduct the dollar you already sent. 
See Reader, page 30 



Letters to the editor and other readers are welcome. Submit to The Computer Journal, 
Post Office Box 12, South Plainfield, NJ 07080-0012. letters may also be electronicalli 
submitted via Internet to "cmcewen@gnat.rent.com," via GEnie™ to "TCj$" or to 
Socrates Z-Node at (908) 754-9067. Submission implies persmission to publish your letter 
unless otherwise stated. Letters may be edited as necessary. 
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The CPU280 

When 8 Bits Aren't Enough 



By Tilmann Reh 



The History 

When Zilog first introduced the Z800 MPU in their 1983/ 
84 data book, I was working with a homebrew Z80 system 
based on ECB-bus EuroCards (a well-estabUshed standard 
here in Europe these days). My system was running with the 
usual 4 MHz clock, but my CP/M-Plus BIOS already had 
some very nice advantages. For example, I had developed the 
AutoFormat system, a technique which supports a wide vari- 
ety of disk formats automatically. The basic principle is the 
same as what MS-DOS uses: the disk contains a parameter 
block which holds all information necessary to process it. 
Another feature was the automatic installation of and adap- 
tation to various peripherals. Since several some people 
around here had similar machines, none of them had to con- 
figure hardware parameters (as long as they didn't need very 
special things). 

When I had a look at the 'preliminary' specifications of 
the Z800, 1 began thinking about some performance improve- 
ments for my system. So I waited for this chip to become 
available. I was still waiting in 1985 when Hitachi's HD 
64180 suddenly appeared. This processor had much of what 
the Z800 was supposed to offer, but it was actually available! 
So 1 gave up waiting any longer and developed a 64180- 
based single board computer. It had the 64180 MPU (with 
both serial channels used), 32 KB EPROM and 512 KB 
DRAM, a 765-type floppy controller for up to four drives, 
and an ECB bus interface on a EuroCard. The clock fre- 
quency was 9.216 MHz, which made an effective Z80 speed 
of about 11 to 12 MHz. Since the ECB bus cannot handle 
these frequencies, the bus clock was only half the CPU clock 
(4.6 MHz), with timing signals stretched to meet standard 
Z80 peripheral requirements. My new 'CPU180' system did 
the work of three of the older boards: the CPU, the memory, 
and the floppy controller board. 

The new single-board design brought the advantage of 
direct access to all basic I/O, so the BIOS could rely on these 
facilities and use them. The CP/M-Plus implementation I 
wrote for that system was more comfortable than the former 
Z80 multi-board version. For example, it introduced 
automatic disk exchange recognition. The high processor 
performance was amazing compared to the 4 MHz Z80. 



Tilmann Reh is an electronics engineer at the Center for Sensor Systems of the 
University of Siegen, Germany. In addition, he owns a small company which 
develops custom specific problem solutions, often using microcontrollers or 
microprocessors. He has been active zvith CP/M since 1983, changed to CP/M-Plus 
in 1985, and has developed a number of ECB-bus boards. Tilmann can be reached by 
regular mail at 'In der Grossenbach 46, W-5900 Siegen, Germany' or by e-mail 
(Internet/bitnet) at 'tilmann.reh@hrz.uni-siegen.dbp.de'. 



Then came the IBM-PCs. At that time CP/M was system- 
atically forced to death here in Europe. The special German 
computer syndrome became, "it has to be always the newest, 
biggest, and fastest machine," and the computer magazines 
followed that slogan. So, after a while 1 was the only one 
around here who was still active with CP/M. That was the 
reason why the CPU180 was built exactly once: 1 was work- 
ing with the prototype board, and no one else seemed to be 
interested. (By the way, Wayne and Paul, if you had known 
that back in 1985/86, you wouldn't have had to design the 
YASBEC!) 

At the end of 1988 Uwe Herczeg, another 'lone CP/M 
user' in Germany, placed an ad in a major computer maga- 
zine asking for other CP/M users to come forward. This 
brought the remaining activists together. But most of them 
were still using 4 or 6 MHz Z80 systems, often also based on 
ECB-bus EuroCards, and some were very interested in my 
CPU180 system. So we began thinking about a redesign of 
that board with state-of-the-art technology. One of those new 
friends suggested using the Z280 instead of the Z180. Z280? I 
ordered the data sheet and what did 1 find but the late incar- 
nation of the old Z800 idea. Unbelievable but true, the Z280 
was really available! So we decided to use the Z280, for this 
CPU has a far more powerful instruction set than the Z180. 

The Hardware Design 

Basics and IVIemory 

As the hardware and software concepts of the CPU180 
had proven themselves very well, all basic principles were 
carried over to the CPU280 design. As it was with the 
CPU180, the highest priority design rule was to get the 
absolute maximum performance out of the MPU with the 
absolute minimum circuit expense and parts cost. For the 
printed circuit board that meant using a standard double- 
sided PCB (no multi-layer) with normal wire thickness (0.25 
mm) and no SMD parts at all. Just tiie good old sort ot 
computer boards: reliable and easy to maintain. 

In order to get the full power of the Z280, it must be run 
in the 16-bit Z-bus mode, with cache and burst-mode en- 
abled, with no RAM wait states, and with the highest pos- 

sible clock frequency (12.5 MHz). The 

on-board memory interface is 16 bits 
wide. 

Main memory is built with dynamic 
RAM. There are eight sockets for 1 M- 
bit or 4 M-bit chips (with 4 bit data 
width). Chips must be used in groups 
of four to fit the 16-bit data bus. So the 
possible memory capacities are 512 KB 
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and 1, 2, or 4 MB. This directly accessible memory should be 
enough for just about any circumstances. The standard con- 
figuration is with eight 1 M-bit chips (1 MB total). To save 
space and because of the availability of exactly pin-compat- 
ible 1 and 4 M-bit memory chips, ZlP-cased RAM is used. 

Having had very good experience with synchronous 
DRAM timing (the CPU180 memory worked absolutely 
error-free for many years), 1 built a fully synchronous timing 
chain for the DRAMs again. This uses an HCT175 as a four- 
bit shift register and a GAL (gate array logic) containing the 
CAS decoding and selection logic. The DRAM interface also 
supports the processor's burst mode, using a GAL to sweep 
the lowest address bits during the burst (we can't use nibble- 
mode RAM's, as these are not available with 4-bit width!). 
The RAM timing is designed to meet all specifications of the 
Z280 at 12.5 MHz and RAMs with 100 ns access time. 
However, as the prices for 100 ns and 80 ns types are 
identical, we normally take the latter for safety. 

Since the memory interface is far too fast for the ECB bus, 
external memory is not supported. Additional reasons for 
this decision were the data bus width (16 bit vs. 8) and the 
different timing and status signals (Z-bus vs. Z80). Support 
for external memory with burst-mode is absolutely impos- 
sible, as the ECB bus doesn't have strobing signals which 
could do that job. Interfacing the fast 16-bit internal data bus 
to the slow 8-bit ECB bus would require a large amount of 
circuitry, and that would violate our main design rule. So, if 
someone really needs more than 4 MB RAM, please connect 
an external I/0-accessed RAM-disk via ECB (DMA support 
is no problem). 

The boot software is placed in two 27C256 or 27C512 
EPROMs, so the boot capacity is 64 KB or 128 KB. For easy 
handling, ordinary 28-pin DIP sockets carry the EPROMs. As 
this memory usually is needed only during boot-up, burst- 
mode is not supported, and to accommodate slower memory 
chips up to three wait states may be added . 

The Z280 is able to use different memory timings when 
accessing the lower or upper half of its 16 MB address space. 
The EPROM is decoded into the lower half (8 MB, what a 
waste!) and the RAM into the upper half. This way, it is 
possible to use the RAM with zero wait-states and burst 
mode while the EPROM uses up to three wait-states and 
doesn't support burst mode. Mapping any desired memory 
configuration to the CPU's logical 64k address space is done 
with the PMMU (Paged Memory Managing Unit) internal to 
the Z280. 

I/O Basics and Bus Interface 

In order to take advantage of widely available Z80 periph- 
erals, the ECB bus clock and corresponding timing signals 
really should not exceed 6 MHz. As the CPU clock frequency 
is 12.288 MHz (for easy baud rate generation, it should be an 
integer multiple of 2.4576 MHz), it is convenient to use half 
the CPU clock frequency. This results in a bus clock of 6.144 
MHz, which requires Z80B or Z80-6 components. With the 
internal wait-state generator of the Z280 programmed to in- 
sert four wait-states every I/O transaction (the maximum 
value), the duration of the 1/0 cycles exactly matches the 
divided clock. The clock divider is implemented by a single 
flip-flop (HCT74) and is reset at the beginning of each trans- 
fer to produce the correct phase relationship between bus 
clock and timing signals. Since the Z-bus control and timing 
signals cannot be used for the ECB bus, they are converted 



into the appropriate Z80-type signals with a GAL. 

Since the external peripherals use Z80-type vectored 
interrupts, the bus interface must be able to generate the 
correct interrupt acknowledge and RETI timings. Interrupt- 
acknowledge is treated as an I/O transaction and stretched 
by the Z280, but the RETI instruction consists of two memory 
cycles, which are too fast for the peripherals (besides the fact 
that the memory control signals do not appear on the ECB 
bus). Last but not least, the Z280 has a new interrupt mode 
(mode 3) which uses another return instruction (RETIL). So a 
slow RETI timing can be simulated using special accesses to 
on-board I/O locations, with a GAL generating the correct 
signals for the ECB bus. This way, vectored external 
interrupts are supported, although the clock speeds are very 
different. 

The Z280 supports 24-bit I/O addresses as opposed to the 
8/16-bit addresses of the Z80. The upper eight I/O address 
bits are accessed via the 'I/O Page Register' within the MPU. 
For full access to the 256 1/0 addresses which are specified 
for the ECB bus, the bus interface is decoded to have an I/O 
page of its own. Another page is used for the on-board I/O, 
and two pages are reserved for the internal I/O registers of 
the Z280. Decoding of the I/O pages and addresses is done 
within GALs. 

Internal and On-Board I/O 

The Z280 comes with a serial interface (UART), three 16- 
bit counter/timer circuits, and four DMA channels on-chip. 
To avoid an external baud rate generator for the UART, one 
of the timers is used. The 12.288 MHz clock allows standard 
baud rates up to 38400 to be generated. Higher, but non- 
standard, baud rates are also possible. 

The internal UART is completed with two handshake sig- 
nals which are not supplied by the MPU. A second serial 
interface is provided by a Twenty-Pin-UART (TPUART) 
COM81C17 by SMC (it includes its own on-chip baud rate 
generator). Both interfaces are buffered and shifted to RS- 
232C levels with a 5V-only line driver and receiver, the 
LT1134. 

The CPU280 contains a real-time-clock (RTC) with 50 
bytes of nonvolatile RAM, the Dallas DS 1287. Since this part 
already contains the lithium battery, no external circuitry is 
required. The RTC is able to generate interrupts at a specified 
date and/or time (alarm) or periodically. The NVRAM is 
ideal for storing configuration parameters. 

Floppy disk I/O is handled by a WD/SMC 37C65 floppy 
disk controller (FDC). This neat chip, cased in a 44-pin PLCC, 
contains the complete controller. Just connect the CPU bus to 
some pins and the disk drives to some other (and don't 
forget the quartz crystal), and everything is running. Floppy- 
related data transfer may be handled by one of the Z280's 
DMA channels. 

Simple TTL chips (HCT367, HCT259) are used to imple- 
ment one 6-bit input port and one 8-bit output port. One bit 
of each port is used for the handshake signals for the first RS- 
232C interface. The other outputs drive some FDC control 
lines and three LED's for status display. Some of the inputs 
are connected to jumpers so that they can be used for con- 
figuration purposes. 

There are four 16V8 type GALs on the CPU280 board. 
They contain memory address and CPU state decoding, I/O 
decoding, RAM timing and CAS decoding, and some 'glue' 
logic. Since nearly all signals are processed with only one 
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logic stage, the standard 'slow' 25 ns GALs are fast enough. 

The entire CPU280 circuit is designed using CMOS tech- 
nology. The internal logic is made with the 74HCT series, 
which is fast enough for nearly every signal. The bus inter- 
face and one timing-critical function in the DRAM interface 
use 74ACT chips. All LSI also are CMOS, and the GALs 
should be taken from the 'Q' series (quarter-power). As a 
result, the complete CPU280 board— fully operating at maxi- 
mum clock speed — draws only about 350 mA from a single 
5V power supply. No other voltages are required. The 32 
chips nearly exactly fill the board space of the EuroCard, 
with just enough space left to avoid a multilayer PCB. (Hey, 
Wayne and Paul, why did you need SMD for just 23 chips?) 

As with every good single-boarder, you just need to con- 
nect a power supply, at least one disk drive of any kind and 
size, and a terminal to complete the CP/M-Plus workstation. 
However, by connecting the CPU280 to a standard ECB 
backplane, you are free to use nearly any available ECB I/O 
board. 

The Software 

The best hardware doesn't produce anything without the 
right software. With this in mind, I adapted my CPU180 
BIOS to the CPU280, now using the powerful Z280 instruc- 
tion set, of course. As with the circuit design, the basic prin- 
ciples and structures of the BIOS were taken directly from the 
CPU180. However, I completely redefined and enhanced the 
AutoFormat system and added a menu-driven hardware 
configuration program to the boot loader (this was impos- 
sible with the CPU180, as it had no NVRAM). Of course, 
some further improvements were made based on the experi- 
ence of four years of CPU 180 operation. 

Normally, the complete system (boot loader, CCP, BDOS, 
and BIOS) is booted directly out of the EPROM. As a result, 
you can boot up your machine in two seconds without any 
noise or mechanical action. (For testing new system versions, 
of course, booting from disk is also possible by pressing a 
button during RAM-test.) 

With all functional enhancements fully compliant with 
CP/M-Plus definitions, all CP/M-Plus and most CP/M-2.2 
software can be run on the CPU280 without any problems. 
By the way, the operating system runs in the Z280's system 
mode, while all user programs run in user mode. This is 
done mainly to achieve easy bank switching (which the 
MMU does automatically in this case), but it also increases 
system security. Unfortunately, CP/M-Plus must have the 
BIOS entry vector and some data structures in common 
memory, so you cannot absolutely prevent user programs 
from damaging the system software. But since we don't have 
any better (and still compatible!) operating system, we have 
to live with that fact. 

The Power 

What is the real performance of a Z280 running with ev- 
ery booster switched on? The answer, unfortunately, is not as 
clear as you would probably like it to be. First, the Z280 is a 
pipelined CPU. So you really can't say how many clock 
cycles any instruction will take; it depends on the last few 
previous instructions. In addition, some instructions (jumps 
and calls, for example) flush the pipeline and thus are rela- 
tively 'slow'. Second, effective CPU speed depends on the 
'hit ratio' of the cache controller. Small loops will run much 
faster than 'spaghetti code'. Third, the 16-bit arithmetic unit 
of the Z280 (opposed to the 4-bit one of the Z80) processes 



indexing and math operations with greater speed gain than 
with other instruction types. So the more a program makes 
use of these instructions, the greater the effective speed. 

Although it is impossible to specify exactly the power of 
the Z280, you can say that with normal 8080 or Z80 software 
it will have the power of a Z80 running at 16 to 20 MHz. Of 
course, using the new instructions (there are more than 600!) 
further increases the performance (while loosing Z80 com- 
patibility, of course). As the Z280 is used more and more, I 
hope we will soon see the first real Z280 programs or the first 
real Z280 operating system (which could could get rid of the 
annoying 62 KB TPA limit of CP/M-Plus...). 

The Development History 

After the first version of the CPU280 ran stably in March, 
1990, 1 made a redesign of the PCB layout with slight changes 
in parts of the circuit. In June, 1990, I ordered the first run of 
PCBs, and in November, 1990, 1 sent them along with all 
semiconductors and special parts to about 25 people here In 
Germany. A few other people around the world got a PCB 
without the part set. 1 had to wait until November because 
that was the time when the 12.5 MHz version of the Z280 
became available, and we didn't want to take the slower ver- 
sion first and upgrade a few months later. As of early 1991, 
many of the machines were running very well, as far as I 
have been informed by the users. The CPU280 has proved 
itself to be very fast and very reliable. Our 'PD and ZCPR 
Man', Helmut Jungkunz, likes the machine for its flexible 
method of processing different disk formats; that's why he 
uses it for nearly all disk distribution he has to do. Of course, 
he likes the raw power, too. 

But the CPU280 is not our only project here in Germany. 
In a future column 1 would like to introduce my next board, 
an IDE controller which connects standard (PC) AT-Bus 
harddisks to any ECB-bus based CP/M system. The board 
also contains an active termination of all bus signals, a Cen- 
tronics printer interface, a four-LED power monitor, and two 
system control buttons for reset and NMI (which, with the 
CPU280, forces a warm system reboot). This board nicely 
matches the CPU280 and allows one to build a really high 
power CP/M workstation. 

A friend of mine is developing an LCD terminal. Together 
with a low-power Z180 single-boarder (based on my 
CPU180) it makes a powerful CP/M-Plus laptop! My newest 
project, which is coming along very well, is a high-perform- 
ance CRT terminal for text and graphics at an unbeatable 
price. Wait and see! Needless to say, all three of these boards 
are EuroCard size. My friends and I look forward to describ- 
ing these projects in future issues of TCJ. 

How to Get a CPU280 

Some of you may be wondering how you can get a 
CPU280 of your own. Well, overseas shipment costs would 
be too high for sending complete kits as we did here in Ger- 
many. I think the easiest way to make the CPU280 available 
in the USA (and elsewhere outside Germany) is for a local 
dealer to provide my PCB together with locally obtained 
components. For the US market, who could do that job better 
than Sage Microsystems East? So, if you are interested in the 
board, the semiconductors, or both, please contact Jay Sage. 
Kits will include a disk with the complete system software, a 
hardware manual describing the circuit details, and a brief 
software description (I still haven't found the time to com- 
plete a real software manual) .• 



The Computer Journal / #53 



Local Area Networks 

Broadband Cabling 



By Wayne Sung 



Ethernet, along with other 'local' area networks (or as the 
British prefer, 'small' area networks), seldom stay small. 
When people start realizing the benefits available from being 
connected to a network, they will quickly want to join. 

An Ethernet can cover quite a lot of area using only base- 
band coax, but there are several drawbacks in trying to ex- 
tend coax beyond one building. The biggest problem is with 
ground differences among buildings. Another problem is 
that the coax does not withstand well the stresses required 
for long pulls in conduit. 

An Alternative to Coax 

There are a number of ways to solve these problems. One 
of these involves the use of broadband cable, that is to say 
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cable television technoi^igy. This type of system often already 
exists on campuses and works quite well for extending Eth- 
ernets. 

One would normally think of a broadband cable as some- 
thing that only delivers services one way, which is the case in 
cable television. Data .services generally need two directions. 
How would we modify an existing cable system to carry data 
services? 

The most straightfoi-ward way would be to add another 
cable. This way each cable would send signals in one direc- 
tion only. There would be a place 
where some electronic equipment 
would receive the signals from one 
cable, process them, and send them 
down the other cable This place is 
called a 'head end', and in the simplest 
case would be an amplifier. 



Let's look at two modems made to constitute a point-to- 
point circuit. Although the two are shown adjacent in the 
figure, they could literally be miles apart. The only require- 
ments are that modem A generate a signal on frequency fl 
and modem B generate one at f2. Modem A would receive at 
f2, and modem B at fl. The offset is generally zero in this 
case. These frequencies can be chosen at random, but in prac- 
tice will correspond to television channel frequencies. This 
allows the best fit if this cable is to carry multiple services. 

A double cable system is simple enough, but the expense 
of installing the second cable is quite high. In fact, in most 
cases it will be less expensive to modify the first cable to 
make it bi-directional. This is where broadband seems like 
magic sometimes, and this is the process I want to explain 
more fully here. 

Splitting the Bandwidth 

Consider that a broadband cable can handle a rather large 
frequency range, typically in the hundreds of megahertz. We 
can divide this frequency range in half, so that one band is 
used for each direction. If we take a piece of coax (up to 
several thousand feet long) and put a number of signals into 
the coax they will stay distinct. 

A piece of wire is basically passive, and so will not cause 
the signals to interfere with each other. Although every sig- 
nal exists everywhere along the wire, this is of no concern. 
We need one more item to make this scheme work. This is 
called a translator. 

A translator takes an input signal and changes its fre- 
quency by some amount. This is exactly the case where a 
television station broadcasts on a certain channel but on cable 
it is in a different channel. There are two common translation 
amounts for data work, 156.25 MHz (called mid-split) and 
192.25 MHz (called high-split). 

Using a mid-split case, and returning to the modem ex- 
ample, modem A will transmit at fl into the coax. The trans- 
lator will receive this, and change it to fl + 156.25 MHz. 
Similarly modem B's signal will be changed to f2 -i- 156.25 
MHz. Thus A will now have to receive f2 + 156.25 MHz and 
B will have to receive fl + 156.25 MHz. 

A complication arises when the cable must be extended 
over much larger distances. There is loss in the cable, so in a 
very long cable signals will start to weaken. It is simple 



Waj/«e Sung has been working with microprocessor hardware and sojtivare for 
over ten years. His job involves pushing the limits of networking hardware m 
attempting to gain as much performance as possible. In the last three years he has 
developed the Gag-a-matic series of testers, which are meant to see if manufacturers 
meet their specs. 
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enough to install amplifiers to bring the signals back up, but 
amplifiers normally work in one direction only. 

Fortunately, since we have already divided the frequency 
range, we can use low- and high-pass filters to split the sig- 
nals and have two amplifiers, one for each direction. One 
reason it is cheaper to modify a cable system for bi-direc- 
tional use is that most likely there is already space for the 
filtere and additional amplifiers. The amplifier enclosures are 
designed for bi-directional use, and adding the second direc- 
tion is fairly simple. 

Typically the low frequency band flows toward the head 
end and the high frequency band away from it. This is not an 
absolute requirement, but in those cases where a cable 
already exists to provide one-way services these will be in the 
high range. For example, if there are television channels, they 
will start at channel 2 (54 MHz). Thus it becomes natural to 
design the two-way system so as not to have to disturb 
existing services. 

In fact, there is a low-split system where all television 
channels are kept intact. However, this leaves very little 
space for one direction. Also, at lower frequencies it is more 
difficult to get good performance from wide-bandwidth 
devices (which we will need when we start extending LANs). 

To add devices, we install taps along the main trunk. 
These taps isolate devices from each other. Remember that all 
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can set the receive levels on the trunk fairly high so that we 
can have some isolation on the receive side as well. It is also 
common to have 10 - 20 dB of receive isolation, but again this 
factor is often compromised due to low levels in the trunk. 
With digital signals, there is a lot of leeway and many 



devices are to send toward the head end and receive from it. 
Individual devices do not need to hear each other, and in fact 
do not benefit from being able to do so. 

RF circuits are easily affected by other circuits operating at 
nearby frequencies, so it pays to keep them isolated. In prac- 
tice, each modem output will be isolated from the trunk by 
10 dB or more, providing 20 dB of isolation from one modem 
to another. Taps are available with multiple branches per 
unit. 

Note that splitters and taps are not the same. A splitter is 
meant to divide the total incoming signal several ways 
equally. A tap provides minimal loss in the through direction 
and a higher loss in the branch. Thus a two way splitter has 
at least 3 dB loss from the input to each output whereas the 
through direction of a tap should have less than 1.5 dB loss. 

If a splitter gets used instead of a tap, the trunk level will 
suffer needlessly. This extra loss then sometimes gets (incor- 
rectly) compensated for by reducing the values of otherwise 
correctly installed taps. Or, the outputs of modems have to 
be run at maximum to get enough working signal. This 
means that normal gain changes over temperature might 
cause intermittent operation. 

Since the two frequency bands are handled separately, we 
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times the system works despite poor practices. If there is 
video being carried, though, the effects will be a lot more 
obvious. 

With proper engineering, a broadband system can do a 
very good job of data distribution. For the most part, it does 
take some vigilance to keep one running well. Even tempera- 
ture differences from winter to summer can cause problems. 
Still, one good technician can keep a fairly large broadband 
system running smoothly (until vacation time). 

Why Not Fiber Optics? 

Given that the cost of fiber optic systems is declining, why 
bother with broadband at all? If we are talking about a totally 
new installation, this is a compelling argument. However, 
although fiber solves the ground difference problem nicely 
(since it does not conduct), it is much more difficult to carry 
multiple services on fiber. 

Individual services, particulady very high bit rate services. 
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are ideal for fiber. However, frequency multiplexing is much 
more difficult (what you would be multiplexing is the color 
of light). Telephone companies are already using fiber optic 
systems carrying gigabits per second, but these are point-to- 
point. 

In a broadband system, any service can be tapped at any 
point using a device which costs only a few dollars. The 
same mechanism does not exist (yet?) for fiber. An ideal situ- 
ation, perhaps, would be to use fiber between buildings and 
broadband inside the buildings. It is possible to take a whole 
broadband cable's content and modulate it onto a fiber. 

Getting Practical 

So much for the general theory of broadband systems. 
How do we use them to extend local area networks? There 
are several different methods available. 

The most direct way would be to design a system where 
the transceiver becomes an rf device, being able to take the 
baseband Ethernet signal and convert to and from an rf sig- 
nal. A computer connected to this kind of transceiver would 
not know it was not baseband in most cases. 

One consideration needed is whether the signal 
transmitted by the computer goes to the head end and back 
before being received by this computer as a confirmation. If 
the signal does make the round trip, this is a delay that the 
computer is not expecting, because a normal transceiver has 
no time delay between transmit and receive. 

If the round-trip delay, which is of course related to the 
size of the plant, exceeds a certain amount, the computer 
might think that it is not able to generate a signal on the 
cable, and not complete the transmission. 

On the other hand, if the rf transceiver is made to echo the 
transmitted signal to the computer, then there is no con- 
firmation that the signal actually went onto the cable. With a 
baseband system, inability to actually generate a carrier 
should cause an error. 

In either case, the total size of the plant will not greatly 
exceed the size of a baseband plant, because the collision 
timing windows don't change. It is possible to build a 
slightly larger plant because collision detect is done at the 
head end, which allows some of the timing to be reallocated. 

By the way, any method of transmitting Ethernet over two 
paths has these considerations. This is true, for example, of 



fiber optic and microwave systems. 

One other disadvantage of the rf transceiver is the wide 
bandwidth required in the rf spectrum. Since the signaling 
rate is not changed, the rf side must still handle a 10 Mb/. s 
signal. This usually ends up requiring two to three TV chan- 
nels (12 - 18 MHz) in each direction and that is a lot to ask 
for. 

One would normally want to be able to use the full size of 
a broadband plant. To be able to do this, the Ethernet timing 
window must be bypassed. This is often done by having the 
rf transceiver receive the entire packet before sending it onto 
the cable. Once the packet is in the transceiver, the timing 
window is satisfied, and a different method can be used in 
the cable. 

This method is called a buffered repeater, although strictly 
speaking a repeater operates in a bit-by-bit fashion rather 
than by packets. Having the extra circuitry increases the cost, 
but fortunately it is not necessary to have one of these for 
each machine. A number of machines can be attached nor- 
mally and then use one buffered repeater to leave the build- 
ing. 

It is then possible to change the signaling rate on the rf 
side to lower spectrum requirements. Note that simply de- 
creasing the signaling rate also extends the distance, although 
this is not usually a good enough tradeoff. 

To get a factor of 10 distance increase requires the same 
factor decrease in speed, and a 1 Mb/s system would feel 
significantly different from a 10 Mb/s system. Thus the rf 
distance gain is usually obtained with a proprietary signaling 
method, or at least one that is not based on CSMA/CD. 

One possibility would be to use a token bus on the rf side. 
The transceiver would convert between the two formats. A 
token bus normally is able to span large distances, because 
access is not mediated using collisions. It happens that some 
token bus systems actually have collision detect require- 
ments, but only for the purpose of adding new stations. 

Most of the time, the conversion from baseband to another 
transmission medium is accompanied by some method to 
separate traffic between machines on the same side of the 
converter (local traffic) from traffic that occurs between ma- 
chines in different locations (remote traffic). Two of these 
methods are bridging and routing, to be more fully described 
next time.# 



Real/52, from page 19 

The major improvements are supposed to be support for 
larger disk partitions and Posix-compliant utilities. 

As I mentioned once before, UC Berkeley is working to 
remove AT&T code from their operating system. Later this 
year, a BSD release — ^but not a complete operating system — 
should be available from them for about $500. 

Desqview/X 

In August, Desqview/X should be released. This package 
will be more than an X terminal on a PC; it will allow pro- 
grams to be written to run on the PC using Xt and Motif. I 
predict that this will be an earth-shaking product— the essen- 
tial bridge between the workstation and the PC worlds. X 
window has already overturned the mini and workstation 
worlds. To have complete transparency of execution across a 
network of heterogeneous machines, and software portabil- 
ity, is an extremely compelling concept. And you don't lose 
any of your old programs either. 



OS/2 2.0 should be available from IBM sometime in the 
fall. This should be an amazing product as well. Supposedly 
it will run Windows code, PM code, X window code, and 
DOS code, all at the same time. 

Next time 

Wow, look at all the X's. And I didn't even mention X.400 
orX.25. Next time I'm going to get away from all this grandi- 
ose complexity and discuss Kotekan, a "small is beautiful" 
operating system for the NS32 by Don Rowe. Meanwhile, 
don't trust anything with capital letters in the middle!© 

Where to write or call: 

Home Control Concepts 
9353-C Activity Road 
San Diego, CA 92126 
1-619-693-8887 or 1-800-CONTROL 
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An Arbitrary Waveform Generator 

Using the Harris RTX2001A 



By Jan Hofland 



{This article is second of a series on the building and programming of a waveform generator for mechanical structural testing. 
The hardware, with schematics, was given in our last issue, where we also began discussion of the softzvare. In this installment, we 
continue with the software and Forth extensions. The series concludes in our next issue with the source code.—hd.] 

register RX and update the value in scratchpad 
RH if the stale data flag is set. Continue this 
loop until the timer interrupt is masked. 

The execution vectors for each of the 16 commands are 
contained in a table called parse that is used for command 
execution. 

Main Operating Loop 

Here is the overall operating loop; 



Commands 

The following 16 specific commands have been imple- 
mented: 

eemimand description 

NOP no operation 

1 fastSine set up to operate in fast sine mode. The next 

value input is the frequency. 

set up to operate in the accurate sine mode. 

The next value input is the frequency. 

set output amplitude, in millivolts, for 

accurate sine output mode. The value following 

this command is used as the output amplitude. 

This value will be truncated to a multiple of 

50 mV. 

set up to output from buffer in circular 

buffer mode 

set up to output from buffer 1 in circular 

buffer mode 

set up to output in ping pong mode starting 

with buffer 

set up to output in ping pong mode starting 

with buffer 1 

set up to output from buffer until it is 

empty 

set up to output from buffer 1 until it is 

empty 

used to select a buffer and load it with data 

values. The next parameter must be the number 
of values to be loaded, up to 2048, and the msb 
set if it is for buffer 1. Then the data values 
are input in sequence. 

set the offset to be subtracted from the 
sinewave value in accurate sinewave mode, in 
100 's of microvolts The next value following 
this command is the offset. 

used to set the filter cutoff point. The next 
value input is used for the filter cutoff, 
range 1 to 40000 Hz. 
13 getPeriod used to input the desired sample rate. The next 
value input is used for the timer period. If 
in either sinewave operating mode, a check is 
performed to readjust the phase increment to be 
consistent with this period and the output 
frequency . 

disable timer interrupt to stop outputting 
points 

enable the timer interrupts to start 
outputting data and then go into a loop to 
repeatedly check the stale data flag in 



2 accuSine 



3 setAmpl 



4 bufLoopO 

5 bufLoopl 

6 pingPongO 

7 pingPongl 

8 bufOutO 

9 bufOutl 
10 IdBuf 



11 setoff set 



12 setPilt 



main ( — ) 

initialize 
BEGIN 
readFifo 
doCmd 
AGAIN : 



begin an infinite loop 

read a command from the input stream 

perform the command 

go do it again 



14 stop 



15 start 



and here is the command execution word: 

: doCmd { n - ) perform the command represented by n 

DUP cmdMsk AND make sure the upper 12 bits are zeroes 
IF if the result of the logical AND is non- 

OROP zero then it is an unrecognized command 
," Unrecognized Command " and discarded an error 
message to the user 
ELSE parse EXECUTE otherwise get an execution vector 
THEN ; from command parse table and execute it. 

Demonstration Software 

Part of the software is for demonstrating some of the ca- 
pabilities of the Waveform Generator. As designed, the 
Waveform Generator expects its commands and arbitrary 
data to be input from the input FIFO. Rather than design and 
debug some hardware for controlling it in this manner 1 
chose to simulate the input FIFO in software. This has some 
impact on the performance realized in the breadboard, but it 
does demonstrate that the operating modes do, in fact, work 
as designed. The basic scheme is to construct a queue of 
commands and data exactly as if they were being input from 
the input FIFO. I then use a revectored input routine to ac- 
cept input from the software queue rather than the input 
FIFO. 
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Input Stream Queue 

A 512 word input queue is con- 
structed using the word buildCQ. This 
queue is called cmdQ. It is used for 
setting up the various demonstrations. 
The way it gets used is to load it with 
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the sequence of command codes each followed by the re- 
quired parameter, if any. The last command entered is the 
start command. Then the queue end pointer and tail pointer 
are adjusted to conform with the actual size of the command 
queue. 

Demonstration Sequences 

There are 6 sequences implemented: 

demoCircSq Implements a 1 Khz square wave using circular 
buffer mode and a 40 Khz filter cutoff. The 
square wave amplitude is a nominal -IV to +1V. 

demoFBine20 Implements a 20 Khz sinewave using fast sine 
mode and a filter cutoff of 2 Khz. 

demoPflinel Implements a 1 Khz sinewave using fast sine 
mode and a filter cutoff of 1 Khz. 

demoAsinel Implements a 1 Khz sinewave using the accurate 
sine mode with a 1 volt RMS amplitude, filter 
cutoff of 1 Khz and an offset of 90 millivolts. 

demoPp Uses the ping pong output mode to output a half 
sine of 1 Khz , pause for 500 microaeconda , 
output another half sine at half amplitude, 
pause for another 500 microseconds, and then 
output a full cycle of 2 Khz sine. Then stop. 
There isn't anything particularly useful about 
this waveforai choice. It just shows some of the 
versatility in output modes. 

demoOnce Uses the once out mode to output one cycle of a 
100 Hz sine that is linearly attenuated to 
zero. 

The Demonstration Loop 

The word choose invokes a menu structure for the user to 
choose which demo to be run and then it runs it. The main 
operating loop for the demonstration is patterned after the 
main high level word of the normal operating environment 
with one difference. Rather than being an infinite loop, it is 
repeated until the command queue is empty. 

The word demo kicks it all off. Here is its definition: 

: demo ( — ) start up a demo 
BEGIN 

choose dVect EXECUTE choose a demo and fetch its 
execution vector from the 
table dVect and execute it. 
This sets up the queue of 
ccanmands and parameters. 
demoMain perform the commands in the 
command queue 
AGAIN ; and repeat it. 



Note that four of the six demos do not have a terminating 
condition. Stop them with the red pushbutton and reinvoke 
demo to perform another one. 

Conclusions 

This model has clearly demonstrated the capability to con- 
truct a waveform generator based on the RTX2001 A. Much of 
the hardware added can be incorporated into an ASIC, if so 
desired. It should be a simple matter to include all of the 
control logic described here into the ASIC. 1 would envision 
keeping the input FIFO off-chip, as well as the DAC and the 
reconstruction lowpass filter. Keeping the added data RAM 
off-chip as well as increasing its size also makes sense. I 
would make the DAC sample clock a dedicated hardware 
timer, as well as the filter clock toggle ocntrol. Of course, 
both of these timers would remain programmable. 

If I were to take the next step in the design, I would 
probably incorporate the following capabilities: 

• Provide a second DAC for range control. This 
would have to be a multiplying type DAC and would 
provide dynamic amplitude scaling of all outputs. I 
expect that a 12 bit DAC would be adequate for this 
purpose. 

• Provice a means of measuring the analog output 
DC offset and correcting for that offset. It turns out that 
as good as the switched capacitor filter is for waveform 
reconstruction, it has rather pcwr DC offset characteris- 
tics. Provision of an 8 bit DAC, possibly on-chip, for 
correcting for offsets makes sense. Another, though less 
versatile, alternative would be an analog servo circuit 
to servo the output toward an average zero level. 

• Provide a means to bypass the filter to allow ran- 
dom noise, wideband outputs. This kind of stimulus is 
useful for some kinds of testing, 

• Provide a user input for shutting down the output 
and for gracefully ramping the output to zero when the 
shutdown occurs. 

Finally 1 must comment on the use of Forth for the 
prototyping environment. In retrospect, I find it amazing that 
I was able to write and debug all the software necessary to 
control this hardware in the matter of about 7 weeks of spare 
time effort. This is the first programming I have done in 
anything other than an academic environment. The language 
lends itself to rapidly start doing something related to the 
application rather than spending all of your time learning 
syntax or trying to relate some obscure command behavior to 
what the hardware is supposed to do.* 



Listing 1. OAL 26CV12 ABEL Source Code 

MODULE mem_addr_decode 
flag '-r4' 

TITLE 'memory address RAM select and filter clock toggle 
control for RTX2001 wavefomi generator 
Jan Hofland 
900404 
900406 
900415 
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cntLatch 
cLoadLo 
filtClk 
reset ( input ) 
resetLo 
gnd 

no_out20 
URAMSEL 
LRAMSEL 
uds ( input ) 
Ids ( input ) 
MA12 (input) 



The purpose of this device is twofold. It decodes a memory 
address to enable the external 8K x 16 RAM. This memory is 
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addressable as either bytes or words. The other purpose of 
the device is to control the programmable counter used to 
provide a clock source for the switched capacitor filter IC. 
The filter requires a clock source 100 times its cutoff 
frequency. For its highest bandwidths (up to 40 KHz), using 
a timer interrupt would require interrupt servicing at a 4 
MHz rate. Instead, what is done is to use a programmable 
down counter to toggle filtClk. The down counter is used for 
divide down of up to 256. For higher divisions, an internal 
timer in the RTX2001 is used to generate an interrupt, and 
the filtClk is toggled by writing to an ASIC bus address. 

modified to change from a 22V10 to a 26V12 device to allow 
full memory decoding of RAM contiguous with the evaluation 
board MAP chip RAM. 

device declaration 
' U05 DEVICE 'P22V10'; 
U3 DEVICE 'P26CV12'; 

' pin declarations 
' inputs 

tclk pin 1; "8 MHz clock input 

GA0,GA1,GA2 pin 2,3,4; " ASIC bus addresses 

grd_wrLo pin 5; "ASIC bus read/write 

gioLo pin 6; "ASIC bus external address active low 
tcLo pin 28; "counter terminal count active low 

MA19,MA18,MA17,MA16 pin 8,9,10,11; "memory bank address 

MAI 5, MAI 4, MAI 3, MA12 pin 12,13,14,15; "upper 4 memory bits 

uds.lds pin 17,16; "memory bus upper and lower data strobe 

reset pin 2 3; "system reset 
" outputs 

cntrNabLo 

cntLatch 



pin 27; "enable filter clock counter active low 
pin 26; "ASIC bus write data to counter data 
"in latch 

cLoadLo pin 25; "counter load control active low 

filtClk pin 24; "filter clock 

URAMSEL,LRAMSEL pin 19,18; "upper and lower byte RAM select 

resetLo pin 22; "active low reset output 

no_out20 pin 20; "unused output 

'constant declarations 
x,z = .X.,.Z.; 
k = .K.; "high-low-high clock pulse 

mAddr = [MA19 ,MA18,MA17,MA16 ,MA15 ,MA14,MA13,MA12 ] ; 

"upper memory address 
gAddr = [GA2 ,GA1,GA0] ; "ASIC bus address 

"pin attributes 

cntLatch, cLoadLo ISTYPE 'com,neg'; 

cntrNabLo, filtClk ISTYPE 'reg,pos'; 

URAMSEL , LRAMSEL ISTYPE 'com,pos'; 

resetLo ISTYPE 'com,neg'; 

EQUATIONS 

disable outputs of I/O pins used as inputs 



reset. EN = 

MA12.EN = 

uds.EN = 

Ids. EN = 



filtClk. RE = reset; "filter clock asynchronous reset 
I resetLo = reset; 

'counter data latch control 

I cntLatch = (gAddr == 6) & !grd_wrLo & IgioLo & itclk 
& 1 reset; 
'counter load control asynchronous set-reset flip-flop 

IcLoadLo = reset "force low if reset active 

# ItcLo & Itclk "set (low) during low half of 

"clock if counter terminal count asserted 

# IcLoadLo & Itclk; "hold asserted during low half 

"of clock reset during high half of clock 
"if reset isn't asserted 

"external RAM selects 
URAMSEL = ((mAddr == 5) # (mAddr == 6) # (mAddr == 7) 



# (mAddr == 8) ) & uds; 

LRAMSEL = ((mAddr == 5 ) # (mAddr == 6 ) # (mAddr == 7) 

# (mAddr ==8)) & Ids; 

" cntrNabLo is a registered signal used to enable the external 

" filter clock down counter. It is set by writing to ASIC bus 

" address 5 and cleared by writing to external address 4. The 

" counter is enabled when cntrNabLo is cleared. The data 

" written to these address is 'don't care'. 

STATE_DIAGRAM cntrNabLo 
state 0: if ((gAddr == 5) & !grd_wrLo & IgioLo) 
then 1 
else 0; 
state 1: if (((gAddr == 4) & lgrd_wrLo & IgioLo) # reset) 
then 
else 1; 

" filtClk is implemented as a toggle flip-flop. If cntrNabLo 

" is low, then the hardware counter is used to toggle filtClk. 

" Since cLoadLo gets asserted whenever the counter reaches 

" terminal count, and the fact that cLoadLo changes the 

" counter control from count down to load, thereby deasserting 

" terminal count out, cLoadLo is used for toggle control. If 

" cntrNabLo is high, then filtClk is toggled by writing to an 

" ASIC bus address. The data is a 'don't care'. 

EQUATIONS 

filtClk. EN = ireset; 

STATE_DIAGRAM filtClk 
state : if (1 cntrNabLo & I cLoadLo 

#cntrNabLo & (gAddr == 7) & lgrd_wrLo & IgioLo) 
then 1 
else 0; 
state 1: if (! cntrNabLo & IcLoadLo 

# cntrNabLo & (gAddr == 7) & lgrd_wrLo i IgioLo) 
then 
else 1; 



TEST_VECTO 


^ ' 


memory sel 


ect' 




( [mAddr 


, uds 


,lds] 


-> [ 


URAMSEL, I 


[ 0, 


0, 


] 


-> [ 


0, 


]; 


[ 1- 


1, 


1 ] 


-> [ 


0, 


]; 


[ 2, 


1, 


1 ] 


-> 1 


0, 


]; 


[ 3, 


1, 


1 ] 


-> 1 


0, 


1, 


[ 4, 


1, 


1 ] 


-> 1 


0, 


], 


t 5, 


0, 


1 ] 


-> 


0, 


1 ) 


[ 5, 


1, 


1 ] 


-> 


1, 


1 ] 


[ 5, 


1, 


] 


-> 


1, 


] 


[ 5, 


0, 


] 


-> 


0, 


] 


[ 6. 


0, 


1 ] 


-> 


0, 


1 1 


[ 6, 


1, 


1 ] 


-> 


1, 


1 1 


[ 6, 


1, 


1 


-> 


1, 


] 


[ 6, 


0, 


] 


-> 


0, 


] 


[ 7, 


0, 


1 ] 


-> 


0, 


1 ] 


[ -1, 


1, 


1 ] 


-> 


1, 


1 ] 


[ 7, 


1, 


] 


-> 


1, 


1 


[ 7, 


0, 


] 


-> 


0, 


] 


[ 8, 


0, 


1 ] 


-> 


0, 


1 ] 


[ 8, 


1, 


1 1 


-> 


1, 


1 1 


[ 8, 


1, 


1 


-> 


1, 


] 


[ 8, 


0, 


) 


-> 


[ 0, 


] 


[ 16, 


1, 


1 ] 


-> 


: 0. 


1 


[ 32, 


1, 


1 1 


-> 


: 0, 


] 


[ 64, 


1, 


1 1 


-> 


; 0, 


] 


[128, 


1, 


1 ) 


-> 


: 0, 


) 


[255, 


1, 


1 1 


-> 


; 0, 


1 



"MAP chip RAM active 



TEST_VECTORS 'filter clock control' 

( [tclk, gAddr, grd_wrLo,gioLo,tcLo, reset] -> 
[cntLatch, CLoadLo, cntrNabLo, filtClk, resetLo] ) 



[ 1, 

[ 1, 
[ 0, 



6, 0, 0, X, 1 ] -> [ 1, 0, 
6,0,C,1,0]->[1,1, 
6,0,0,1,0]->[0,1, 



[1,6,0,0,1,0]->[1,1 



0, z, ]; "reset 

0, 0, 1 ); 

0, 0, 1 ] ; "counter 

" latch enable 
0, 0, 1 ]; 



[ 1, 5, 0, 0, 1, ] -> [ 1, 1, 0, 0, 1 
-32" [ k, 5, 0, 0, 1, ] -> [ 1, 1, 1, 0, 1 
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" cntrNabLo high 
[ k, 4, 0, 0, 1, ] -> [ 1, 1, 0, 0, 1 ]; "set 

" cntrNabLo low again 
t 1, 0, 0, 0, 0, ) -> [ 1, 1, 0, 0, 1 ]; "counter at 

"terminal count 
t 0, 0, X, X, 0, ] -> [ 1, 0, 0, 0, 1 ]; "counter 

" load 
[ 0, 0, X, X, 1, ) -> [ 1, 0, 0, 0, 1 ]; 
"37" [ 1, 0, X, X, 1, ] -> [ 1, 1, 0, 1, 1 ]; "toggle 

"filtClk 
[ 1, 0, 0, 0, 0, ] -> [ 1, 1, 0, 1, 1 ]; "counter at 

"terminal count 
t 0, 0, X, X, 0, ] -> [ 1, 0, 0, 1, 1 ]; " counterload 
"40" [ 0, 0, X, X, 1, ] -> [ 1, 0, 0, 1, 1 ]; 

[ 1, 0, X, X, 1, ] -> [ 1, 1, 0, 0, 1 ]; "toggle 



{ k, 5, 0, 0, 1, ] -> [ 1, 



"filtClk 

1, 1, 0, 1 ]; "set 

"cntrNabLo high 



[ 1, 0, X, X, 1, 


] -> [ 


1, 


1, 


1, 


0, 


1 1; 


44" [ 1, 7, 0, 0, X, 


] -> [ 


1, 


X, 


1, 


0, 


1 1; 


"program control 


toggles : 












[ k, 7, 0, 0, X, 


] -> [ 


1, 


X, 


1, 


1, 


1 1; 


46" [ k, 7, 0, 0, X, 


] -> [ 


1, 


X, 


1, 


0, 


1 1; 


[ k, 7, 0, 0, X, 


] -> [ 


1, 


X, 


1, 


1, 


1 l; 


48" ( k, 7, 0, 0, X, 


] -> t 


1, 


X, 


1, 


0, 


1 ]; 



END mem addr decode 



Listing 2. GAL 22CV10 Abel Source Code 

MODULE a3ic_bus_ccntrol 
" flag '-r4' 

TITLE 'ASIC bus address decode and ADC strobe control 
for RTX2001 waveform generator 
Jan Hofland 
900404 



Vcc 

GDC tri-state 

GDI tri-state 

serDatLd 

DACltch 

Qd local state variable 

Qc local state variable 

Qb local state variable 

Qa local state variable 

fifoRdLo 

fifoWrLo 

reset 



" The purpose of this programmable device is to load a 16 
" bit shift register from the external ASIC bus and shift its 
" output into the serial DAC, and strobe the DAC LE (Latch 
"Enable) input after 18 data bits are shifted into the DAC. 
" Data is shifted in most significant bit first at an 8 MHz 
" rate. The last two bits are always zero. This device also 
" controls writing to the FIFO and reading from it. If the 
' FIFO is full, then writing is inhibited, and if it is 
' empty, then reading is inhibited. The two FIFO status bits 
' can be read on the lower two bits of the ASIC bus. 

'device declaration 
U8 DEVICE 'P22V10': 



'pin declarations 

' inputs 

tclk pin 1; 

GA0,GA1,GA2 pin 2,3,4 

grd_wrLo pin 5; 

gioLo pin 6; 

noUse7,noUse8 pin 7,8; ' 

strobLo pin 9; 



+„. 


-u + 


tclk 


1 


24| 


GAO 


2 


23| 


GAl 


3 


22 1 


GA2 


•1 


211 


grd_wrLo 


5 


20| 


gioLo 


£ 


19 1 


noUse7 


7 


18| 


noUseS 


8 


17| 


StrobLo 


9 


16 1 


fifoMtLo 


10 


15| 


fifoFulLo 


11 


14| 


gnd 


12 


13| 



fifoMtLo, f if oFulLo pin 
reset pin 13; 



"8 MHz clock out of RTX2001 
; "ASIC bus register address 
"ASIC bus read/write 
"ASIC bus external access enable 
"unused inputs pulled up 
"external FIFO data write strobe 
" pulled low to request a write. Set 
" High after fifoWrLo goes low. 
" fifoWrLo then goes high again to 
■ write data into FIFO. User must 
" leave data valid at least 250 ns 
' after setting strobLo high. 
10,11; "FIFO status signals 
'system reset inhibits FIFO read/write 



'outputs 
GD1,GD0 

serDatLd 
DACltch 



pin 22,23; "ASIC bus data lines for reading 

"status 
pin 21; "shift register load control 
pin 20; "DAC latch enable signal 
Qd,Qc,Qb,Qa pin 19,18,17,16; "counter state variables 



"used for generation of DACltch 
fifoRdLo pin 15; "ASIC bus controlled FIFO read 

"active low 
fifoWrLo pin 14; "FIFO write signal active low 

"constant declarations 
x,z,c,k = .X., .Z. , .C. , .K.; 

gAddr = [GA2,GA1,GA0] ; "ASIC bus register address 
sCnt = [Qd,Qc,Qb,Qa]; "shift register control variables 



"pin attributes 
GDI , GDO 
Qd,Oo,Qb,Qa 
SerDatLd 
DACltch 
fifoRdLo 
fifoWrLo 



ISTYPE ' com , pos ' ; 

ISTYPE 'reg,po3'; 

ISTYPE 'com,pos'; 

ISTYPE ' com , pos ' ; 

ISTYPE 'com,neg'; 

ISTYPE ' reg , neg ' ; 



STATE_DIAGRAM sCnt 

" a 16 state gray code counter is implemented. The idle state 
" is state 0. If the DAC shift register is loaded, the 
" counter will progress through 16 state to state 1000, set 
" the DACltch signal, and then reverse direction. When it 
" gets back to state 1010 it will then go to the idle state 
" 0000. DACltch will get cleared 1/2 clock cycle later to 
" strobe the serial data into the DAC. 
state "bOOOO: 

if (I reset & (gAddr == 0) i IgrdwrLo & IgioLo) 

then "bOOOl 

else "bOOOO; 
state 'bOOOl: 

if (1 reset) 

then "bOOll 

else "bOOOO; 
state "bOOll: 

if (1 reset) 

then 'bOOlO 

else "bOOOO; 
state 'bOOlO: 

if (1 reset) 

then ""bono 

else 'bOOOO; 
state "bOllO: 

if (1 reset) 

then 'bOlll 

else "bOOOO; 
state 'bOlll: 

if (1 reset) 

then "bOlOl 

else "bOOOO; 
state "bOlCl: 

if (I reset) 

then 'bOlOO 

else ""bOOOO; 
state *b0100: 

if (1 reset) 

then 'bllOO 

else 'bOOOO; 
state 'bllOO: 

if (! reset) 

then 'bllOl 

else "bOOOO; 
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state "bllOl: 
if (! reset) 
then 'bllll 
else "bOOOO; 
state 'bllll: 
if (I reset) 
then "blllO 
else "bOOOO; 
state "blllO: 
if ( t reset ) 
then "blOlO 
else *bOOO0; 
state 'blOlO: 

if (Ireset & IDACltch) 
then "blOll 
else "bOOOO; 
state 'blOll: 

if (Ireset & IDACltch) 
then 'blOOl 

else if (ireset & DACltch) 
then "blOlO 
else "bOOOO; 
state 'blOOl: 

if (Ireset & IDACltch) 
then "blOOO 

else if (Ireset & DACltch) 
then "blOll 
else 'bOOOO; 
state "blOOOs "turn-around state 
if (Ireset) 
then "blOOl 
else 'bOOOO; 

EQUATIONS 

fifoWrLo.RE = reset; "asynchronous reset of all flip-flops 

serDatLd = (gAddr == 0) & IgrdwrLo & IgioLo; 



1, X, 

1, 0, 

0, 0, 

1, 0, 
1, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
k, X, 
0, X, 



X, 



X, 1, 

0, 0, 
0, 0, 

0, 0, 
X, 1, 
X, 1, 

X, 1, 
X, 1, 

X, 1, 
X, 1, 

1, 

1, 
1, 

1, 

1, 
1, 
1, 
1, 
1, 
1, 
1, 
1, 
1, 
1, 



] -> [ , , ] ; 
] -> [ 0, 1, ]; 
] -> [ 0, 1, 1; 












] 

1 

1 

] 

1 

] 

] 

1 

] 

1 

] 

) 

] 

] 

] 

1 




"load shift register 
" when tclk to 1 



[ 1, 
[ 3, 



] -> [ 

] -> 

1 -> 

1 -> 



[ 1, 1, 
0, 
0, 
2, 0, 
[ 6, 0, 
[ 7, 0, 
( 5, 0, 
[ 4, 0, 
[12, 0, 
[13 
[15, 
fl4 



1; 
1; 
]; 
]; 
]; 
]; 
]; 
); 




0, 



[10, 

(11, 

[ 5, 
I 8, 
[ 9 



[11, 0, 

[10, 0, 
[ 0, 0, 



]; 
l; 
]; 
); 
]; 
1 
1 
1 
1 
1 



"turn around 



] -> [ 0, 0, ]; "DACltch cleared 



TEST 



DACltch. EN = Ireset; 



"tri-state connection to DAC if 
"reset active 
DACltch = (sCnt == 8) "set at turn-around state 

# DACltch & (tclk # (Qd & IQc)); "not reset condition 

IfifoRdLo = (gAddr == 1) & grd_wrLo & IgioLo & Itclk & 
fifoMtLo & Ireset 

# IfifoRdLo & Itclk; "hold low if last read of 

"fifo asserts fifoMtLo 
IfifoWrLo := Ireset & IstrobLo & fifoFulLo 

# Ireset & IstrobLo & IfifoWrLo; " hold low if 

" writing last word in FIFO sets 
" fifoFulLo 

GDI. EN = (gAddr == 3) S. grd_wrLo & IgioLo; "status read 
" tri-state enable 

GDI = 1 fifoFulLo; 

GDO.EK = (gAddr == 3) & grdwrLo & IgioLo; "status read 
" tri-state enable 

GDO = 1 fifoMtLo; 

TEST_VECTORS ' serial data control ' 

([tclk, gAddr, grd_wrLo,gioLo, reset] -> 

[ sent , serDatLd , DACltch ] ) 
[ 0, X, X, X, 1 1 -> [ 0, X, z ]; 



VECTORS 'FIFO control i status' 
tclk , gAddr , grd_wrLo , gioLo , strobLo , f i f oMtLo , 
fifoFulLo, reset) -> [fifoRdLo, fif oWrLo,GDl,GDO] ) 



X, 



X, X, 



X, 



0, 
0, 
1, 
k, 
k, 
k, 

1, X, X, 

k, X, X, 
k, X, X, 
k, X, X, 
1, X, X, 
k, X, X, 
k, X, X, 



X, 1, 1, X, 



1, 1. 



1, 1, 



1, 1, 1, 

0, 1, 1, 

0, 1, 0, 

0, 1, 0, 

1, 1, 0, 



1 ] -> ( 1, 1, 

] -> [ 1, 1, 

1 -> [ 1, 

] -> [ 1, 

] -> [ 1, 

] -> [ 1, 

] -> [ 1, 

1 -> [ 1, 

] -> [ 1, 

1 -> [ 1, 

] -> [ 1, 

1 -> [ 1, 

] -> [ 1, 



]; 



1, 1, 

0, 1, 

1, 1, 
1, 1, 

0, 1, 

0, 1. 

1, 1. 
1, 1, 

0, 1, 

1, 1, 
1, 1, 

1, 3, 

0, 3, 

1, 3, 
1, 3, 

0, 3, 

1, 3, 
1, 3, 

0, 3, 

1, 3, 



1, 0, 

1, 0, 

1, 0, 

1, 0, 

1, 0, 

1, 0. 

1, 0. 

1, 0, 

1, 0, 

1, 0, 

1, 1, 

1, 0, 
1, 0, 

1, 1, 

1, 0, 
1, 0, 

1, 1. 

1, 0, 
1, 0, 

1, 1, 



1, 1, 

1, 1, 

1, 1, 

1, 1, 

1, 1, 

1, 0, 

1, 0. 
1, 0, 

1, 0, 
1, 0, 

1, 0, 
1, 0, 



1 

] 

1 

] 

] 

] 

] 

] 

] 

1 



-> 

-> ( 1, 

-> [ 0, 

-> [ 0, 

-> [ 1, 

-> [ 1, 

-> [ 1, 

-> ( 1, 



1, 1, 

0, 1, 

1, 1, 

1, 
1, 
1, 

1, 
1, 
1, 
1, 



z ]; 
z 1; 
z ]; 
z ]; 

2 ]; 



1; 

]; 
); 



"FIFO write 



"FIFO full 



"FIFO read 



z, z 



"empty 
"again 



"no read 



1, 1, 
1, 1- 



] -> [ 1, 



z ]; 



1, 1, 0, 



1 

] 

] 

] -> [ 

] -> [ 



[ 1, 
[ 1, 



1, o> 
1, z. 



1; 



[ 1, 1, 0, ]; 



[ 1, 1, 



0, 
z , 
1, 



1; 

]; 
1; 



"status 
"read 
"FIFO empty 



"FIFO full 



-> [ 1, 

-> [ 1. 



1, ]; 



END aaic bus control 



"The best executive is the one who has 
sense enough to pick good people to do 

what he needs done, and self-restraint 

enough to l<eep from meddling with them 

while they do it," 



"Most of us are broad-minded enough to 
admit there are two sides to every 
question — our own and the side no 
intelligent, informed, sane and self- 
respecting person could possibly hold," 
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Glossary for Words Added to EBForth 



Boot Cod* Glossary 

#Que ( addr - n ) 



>Cbuf ( n addr - ) 
>Que ( n addr - f 

( n addr — 
>RH ( n - ) 

accuPt ( — n ) 

accuSine ( - ) 

bufLoopO ( - ) 

bufLoopl ( — ) 

bufMax ( - 2048 ) 

bufOutO ( - ) 

bufOutl ( - ) 

buildCQ ( n - ) 



buildDQ ( n - ) 



calcFreq ( - ) 



calcint ( nl n2 - ) 



IcalcPhaselnc ( freq 



to 
in 



to 
in 



Return the number of values in the 
queue whose name is addr. reading a 
value from the data input source. 
Normally, this variable points to the 
hardware FIFO read routine. For 
demonstration purposes, it points to 
fetching values from the software 
command queue. 

Insert n into the queue whose name is 
addr. 
fig ) Store n into the queue whose name 
is addr and return a FALSE flag if the 
queue isn't full. 

n addr tflg ) If the queue is full, 
return the value, the address, and a 
TRUE flag, indicating that there isn't 
any room in the queue. 

Write n to the RH register and clear 
the stale data flag kept in the RX 
register. This flag gets set whenever 
data is transferred from RH to the 
output DAC. 

Return the sine of the current value 
of phase and delPhase scaled to a 50 
mV increment and then the current 
offset is subtracted from it. Used to 
get the output value in accurate sine 
mode. 

Accurate sinewave mode command. Sets 
up the correct mode, the next point 
execution vector, and the sinewave 
frequency. 

Circular buffer mode. Sets up 
output data from data buffer 
circular buffer mode. 
Circular buffer mode. Sets up 
output data from data buffer 1 
circular buffer mode. 

A constant. Corresponds to the size of 
the maximum data queue, in words. 
Output from buffer until it is 
empty. 

Output from buffer 1 until it is 
empty. 

Create a queue structure in code space 
of n words. A defining word. The name 
of the structure should follow 
buildCQ. Sets up and initializes the 
#values variable, the head pointer for 
extracting values from the queue, the 
tail pointer for inserting values, and 
the end pointer for determining when 
to loop back to the beginning, and it 
allocates the necessary space to 
contain n vlues. 

Create a queue structure in data space 
of n words. A defining word. The name 
of the queue should follow buildDQ; 
e.g., 50 buildDQ fudd will build a 
queue named fudd that will hold 50 
values. Sets up the #values variable, 
the head, tail, and end pointers, and 
allocates space for n values. 
Calculate the actual sinewave 
frequency from the known values of 
timebase period and phase increment. 
Because of the quantized nature of 
these parameters, the actual output 
frequency may differ somewhat from the 
set frequency. 

Calculate the required timebase period 
from the phase increment and sinewave 
frequency. Also checks the period to 
make sure that it is at least the mode 
dependent minimum. 
- ) Calculate the required phase 



Cbuf> ( addr - n ) 

circBuf ( — ) 

clearQ ( addr - ) 
cntMsk ( - OFFF ) 
cntrDisabl ( - ) 

cntrEnabl ( — ) 
cosAdj ( — n ) 

cutoff ( - addr ) 
DACl ( n - ) 

delPhase ( - addr ) 

delPhase Inc ( - addr 

div512 ( nl - n2 ) 
doCmd ( n - ) 

DOES> ( - ) 



DQO ( - addr ) 
DQl ( - addr ) 
fastsine ( - ) 



fifog ( - n ) 
fifoFul? ( - fig ) 

fifoMT? ( - fig ) 

filtCntl ( n - ) 



{ hardware ) 
writes to ASIC 
as a write only 



increment from the set frequency for 

sinewave output. 

Fetch the next value from the queue 

whose name is addr. No checking is 

done to see if the queue is empty. 

Most useful for outputting from a 

circular buffer where the data output 

sequence is repetitive. 

Circular buffer output mode. Fetch the 

next value from the current data 

buffer and load it into the RH 

register to be output to the DAC. 

Initialize the iCvalues, the head 

pointer and the tail pointer for the 

queue specified by addr. 

A constant. A mask used for setting 

the number of data values input with 

the IdBuf command. 

Disable the filter clock 

counter. This word 

address IC (hex) 

pseudo register. For low values of 

filter cutoff, the filter clock is 

controlled with timer 1 interrupts. 

Enable the filter clock (hardware) 

counter. 

Return the cosine adjust value for the 

current values of phase and delPhase. 

Used in the accurate sine output mode. 

A variable for the lowpass filter 

setpoint. 

Write the 16 bit value to the DAC 

shift register on the ASIC bus. Writes 

to ASIC address 18 (hex). 

A variable for incremental phase 

interpolation. Used in accurate sine 
mode to keep track of the incremental 

sinewave phase between adjacent values 

of phase . 
)A variable for adding to the 

incremental phase accumulator. This 
value is added to delPhase tor each 
new output calculation in accurate 

sine mode. 

Divide nl by 512 truncated toward 

(not floored). Used in calculation of 

the cosine adjust value in accurate 

sine mode. 

Execute command n, where n is an index 

into the table of command execution 

vectors, parse. This word makes sure 

that the command input from the input 

stream (the input FIFO) is a valid 

command and then executes it. 

An immediate word to define the 

runtime behavior of a word created in 

code space. Typically used for 

addressing or fetching values from a 

table. Uses _DOES. 

Start of data queue 0. 

Start of data queue 1 . 

Fast sinewave mode command. Sets up 

the mode, the next output routine 

execution vector, and the sinewave 

frequency for the fast sinewave output 

mode. Expects the next word in the 

input stream to be the desired 

sinewave frequency. 

Read a value from the input FIFO on 

the ASIC bus. Reads from ASIC address 

18 (hex). 

Return a TRUE flag if the input FIFO 

is full. Reads the input FIFO status 

bits from ASIC address IB (hex) and 

masks bit 1 . 

Return a TRUE flag if the input FIFO 

is empty. Reads the input FIFO status 

bits from ASIC address IB (hex) and 

masks bit 0. 

Write an 8 bit value to the filter 
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GOES> ( - ) 
getPeriod ( - ) 
goftdr ( - addr ) 
initTimers ( - ) 
initialize ( - ) 

intSetup ( — ) 
IdBuf ( - ) 



main ( — ) 



maxBW ( - 40000 ) 



maxFreq ( mode - n ) 



minBW ( - 1 ) 



minlvai ( mode - n2 



mode ( - addr ) 
newAccuPt ( - ) 

newPhase ( - ) 
newPt ( - ) 

nextPt ( - ) 

offset ( - addr ) 
onceOut ( — ) 



clock hardware counter load register 
at ASIC address IE (hex). Only the 
lower byte of n is used. The upper 
byte is a don't care. 

An immediate word to define the 
runtime behavior of an array stored in 
data space. Uses _DOES. 
Get the sample rate from the input 
stream and set the required timebase 
period into the timer load register. 
A variable. Contains the execution 
vector for the mode dependent output 
update routine. 

Initialize the timer clock sources to 
the internal TCLK source and mask off 
all three timer interrupts. 
Initialization routine. Seta up the 
default to fast sinewave output mode, 
40 KHz lowpass filter cutoff, and data 
buffer as the current read buffer 
and write buffer. 

Load the interrupt vectors for the 
timer and timer 1 interrupt service 
routines . 

Buffer load command. Specifies which 
buffer to put the data into, and how 
many data points, followed by those 
data points. Expects the next word in 
the input stream to be the number of 
data values to follow with the most 
significant bit set if using buffer 1 
or clear if using buffer 0. This is 
followed by the data values to be put 
into the data buffer. 

The main high level loop when 
inputting commands from the input 
FIFO. This command is an infinite loop 
of reading a command from the input 
stream and then execute that command. 
A constant corresponding to the upper 
limit for setting the lowpass filter 
(in Hz) . 

A table of upper limits on sinewave 
frequency dependent on output sinewave 
mode. 

A constant corresponding to the lower 
limit of lowpass filter cutoff (in 
Hz). 
)A table of sample rate minimum values. 
Indexed by the operating mode. These 
values are based on the amount of time 
necessary to calculate or fetch the 
next output value to be put into the 
DAC and then respond to the timer 
Interrupt to output it. There isn't 
much time to do anything else. 
A varible corresponding to one of five 
defined output operating modes. 
Load the sine of the current phase 
into RH and clears the stale data flag 
in RX when operating in accurate sine 
mode. Also updates the phase variables 
for the next point to be output. 
Calculate the next phase and delPhase 
for accurate sine mode output. 
The timer interrupt service routine. 
Transfer the value in the RH register 
to the DAC shift register and set the 
stale data flag in RX. 
Put the next sinewave point to be 
output into the RH register and update 
the phase variables for the next 
output point when operating in fast 
sinewave output mode. 

A variable that is subtracted from the 
scaled output value when operating in 
accurate sinewave mode. 
Single buffer output mode. Output the 
data in the current read buffer until 
the buffer is empty and then stop. 



parse 



pbStop ( - ) 



peeQue ( addr - n ) 



phase 



( - addr > 



phaseAdj ( nl - n2 ) 



phaseinc ( - addr ) 



pi/2 



( - 200 ) 



pingPong ( - ) 



pingPongO 
pingPongl 
Que> 



) 



) 



scale 



scaleTop ( 
setAmpl ( 



( n - addr ) A table of execution vectors for the 
recognized commands input from the 
input stream. 

The NMI Interrupt Service Routine, 
performs an abort and outputs a 
"Stopped" message when the pushbutton 
input is sensed active. Used to 
'recover' from an output mode that 
doesn't have an explicit stopping 
condition, or to recover from 
software bug running away with the 
machine. Wish I had this one early in 
the development... 

Return the top value from the queue 
whose name is addr without changing 
the read (head) pointer. 
A variable used for the phase 
accumulator in fast sinewave and 
accurate sinewave output modes. 
Adjust phase point nl to be within one 
cycle. Keeps the phase variable from 
exceeding two pi radians (equivalent) 
A variable for the phase increment to 
add to phase in fast sinewave and 
accurate sinewave output modes to 
determine the next sinewave point to 
be output. 

A constant corresponding to the number 
of points in one quadrant of the 
sinewave table. 

Ping pong output mode. First output 
data from the current data buffer 
until it's empty and switch to the 
other buffer and output data from it 
until it is empty. Then stop 
outputting. 

Ping pong output mode starting from 
buffer 0. 

Ping pong output mode starting from 
buffer 1. 
( addr - n tflg ) Fetch the next value from the 
queue at addr and return a TRUE flag 
if the queue wasn't empty 
( addr - fflg ) or return a FALSE flag if the 
queue is empty. 

A variable. Contains the address of 
the current data buffer to be read 
from. 

A variable used to scale the output 
sinewave in increments of 50 mV when 
operating in accurate sinewave output 
mode . 

A constant. The maximum value for 
scale. 

Set output amplitude command. Used if 
operating in accurate sinewave output 
mode. Expects the next value in the 
input stream to be an output amplitude 
expressed in millivolts RMS. Quantizes 
the input to be a multiple of 50 mV 
and stores it in the scale variable. 
)Set the buffer at addr to a size of n 
words. This routine is typically used 
when using a data or command buffer 
size different than the default 
maximum size. 

Set up the lowpass filter for a cutoff 
of n Hz. Also determines if the 
hardware counter or timer 1 will be 
used for controlling the filter clock. 
Set lowpass filter cutoff command. 
Expects the next value in the input 
stream to be the filter cutoff in Hz., 
range 1 to 40000. 

Set the sinewave frequency and set the 
sample rate corresponding to that 
frequency and the output mode. 
Set output offset command. Used if in 
accurate sinewave output mode. Expects 
the next value in the input stream to 



readPtr ( - addr ) 



( - addr ) 



40 ) 



) 



setBufSiz ( addr n 



setCutoff ( n - ) 



setFilt ( - ) 



setFreq ( freq - ) 



setOffset ( - ) 
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setPeriod 



sineFreq ( 
start { 
stop ( 
stop? ( 
table ( 



tbPeriod ( - addr ) 



toglFC { - ) 



twoPi ( - 800 ) 

U> ( 

UMAX ( 

UMIN ( ul u2 - V 

writePtr ( - addr ) 

DOES ( 
readFifo 



be the offset in 100 's of microvolts. 
No scaling or bounds checking is 
performed on this value. The value 
input is subtracted from the scaled 
value of sinewave output. 
( period - )Set the timebase sample rate (timer 
load register value). Makes sure that 
it is at least the mode dependent 
minimum value. If in a sinewave output 
mode then it also readjusts the phase 
increments to be consistent with the 
desired output frequency and the 
desired sample rate. 

- n ) An 800 point table of sine values 

scaled to 2 VRMS. Used in both fast 
sinewave and accurate sinewave output 
modes. In fast sinewave mode the 
output values are taken directly from 
this table. In the accurate sinewave 
mode interpolation is performed for 
values in between the table values. 
This table is in code space. 

- addr ) A variable corresponding to the 

sinewave output frequency. 

- ) Start output command. Unmasks timer 

interrupts . 

- ) Stop output by disabling the timer 

interrupt . 

- fig ) Return non-zero if the timer 

interrupt is masked off. 

n — ) A defining word to create a data table 
of n values in code space. Returns the 
nth value when invoked at run time. 
A variable corresponding to the 
programmed value of timer counter. 
The actual interrupt period from timer 
will be one more than this value (in 
increments corresponding to the 8 MHz 
TCLK). 

Toggle the filter clock output if not 
using the hardware timer to control 
it. Writes to ASIC address IF (hex) to 
cause the filter clock output to 
toggle . 

A constant corresponding to the number 
of points used to represent one cycle 
of a sinewave in the sine table. 

ul u2 - fig ) Return TRUE if unsigned ul is 
greater than unsigned u2 . 

ul u2 — u ) Unsigned version of MAX. Return 
larger of ul and u2. 
) Unsigned version of MIN. Return 
smaller of ul and u2 . 

A variable. Contains the address of 
the current data queue to load data 
into. 

- ) A low level word in building GOES> and 
DOES>. 

( - n ) Read a value from the input FIFO. 
Waits until there is a value in the 
FIFO. 



the 



the 



Danonatration Softwar* Glossary 

>cq ( n - ) load n into the command queue. Used 
for simulating the hardware input 
FIFO. 

_rdCQ ( - n ) Return the next value from the command 
queue. The normal command fetch is 
revectored to this word for the 
demonstration . 

atst ( - ) A simple performance test to find the 
minimum and maximum number of clock 
cycles to execute tst. This loops 
10000 times. 

btst ( - ) A simple performance test to find the 
minimum and maximum number of clock 
cycles to execute tst for the ping 
pong and once out demonstrations. 
Repeats tst 40 times. 



choose ( — n ) 
cmdQ ( - ) 



cmdQMT? 
cqMax 
dMenu 
dVect 

demo 



- fig ) 

- 512 ) 

- ) 

nl - n2 ) 

- ) 



demoAsinel ( — ) 

demoCircSq ( — ) 

demoFsinel ( — ) 
demoFsine20 ( - ) 
demolnit ( — ) 

demoMain ( — ) 

demoOnce ( — ) 
fixCQ ( - ) 
high ( - addr ) 
low ( - addr ) 
shoParms ( — ) 



shoSparms 



tst ( - ) 



Select one of the 6 demos or quit. 
The start of a circular buffer 
structure in code space for simulating 
the hardware command FIFO. This 
command queue is preloaded with the 
command codes and associated 
parameters and data. Then the command 
execution software is revectored to 
fetch words from the command queue 
instead of the input FIFO. 
Return a TRUE flag if the command 
queue is empty. 
A constant. Maximum size of the 

in words. 

[lenu for selecting a 



demonstration 
value nl comes 



mode 
VRMS 



mode 



command queue 

Display the 

demonstrat ion . 

Return the nlst 

execution vector. The 

from the word choose. 

The high level word for initiating the 

demonstration. 

Demonstrate the accurate sinewave mode 

with a 1 KHz sinewave output, 1 VRMS 

out, 9 00 mV offset, lowpass filter set 

to 1 KHz. 

demonstrate the circular buffer 

operating mode by outputting a 1 KHz 

square wave between +1V and -IV. 

Filter cutoff set to 40 KHz. 

Demonstrate the fast sinewave 

with a 1 KHz sinewave output, 2 

out, lowpass filter set to 1 KHz. 

Demonstrate the fast sinewave 

with a 20 KHz sinewave output, 2 VRMS 

out, lowpass filter set to 20 KHz. 

Initialize the software for running 

the demonstration. Performs the same 

initialization as the normal software 

with the exception of the read FIFO 

command vector . 

The demo version of the high level 

operating loop. This loop is the same 

as the normal main loop, except that 

it terminates when the command queue 

is empty. 

Demonstrate the single buffer 

operating mode. Generates one cycle of 

a 100 Hz sine that is linearly 

lattenuated to zero. 

Adjust the tail pointer and end 

pointer of the command queue after 

loading the queue to account for its 

actual size. 

used for some simple 
testing. Used to keep 
track of the maximum number of clock 
cycles to execute tst. 

A variable used for some simple 
performance testing. Used to keep 
track of the minimum number of clock 
cycles to execute tst. 

Show some of the parameters for the 
current operating mode if the 
operating mode is a sinewave mode. 
Displays the current values of phase, 
phase increment, delta phase, delta 
phase increment, frequency, offset, 
and scale value. 

( — ) Displays some of the 
variable values relevant to the 
current operating mode. Shows the 
values pertinent to a sinewave if in 
one of those mode and displays the 
lowpass filter cutoff and the output 
sample period. 

A test loop similar to the normal 
operating loop. Used for some simple 
timing tests. This word puts a new 
value into the DAC and then generates 
the next output value and puts it into 
the holding register. 



A variable 
performance 
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Real Computing 

RBOCs, C Sickness, HST Modems, Metal and More on Minix 

By Rick Rodman 



A Dark Day in the Computer World 

July 25, 1991 was a dark day in the history of computers. 
On that day, Judge Greene reluctantly permitted the RBOCs 
into the information-providing business. He was not pleased 
with this himself, but felt that the Justice Department had left 
him no choice. He foresaw that this will lead to "the elimina- 
tion of competition from that market and the concentration 
of the sources of information of the American people in just a 
few dominant, collaborative conglomerates, with the captive 
local telephone monopolies as their base." 

Why is it so bad that the RBOCs are allowed into this 
business? After all, won't it result in more and better choices 
for the customer? Let's look at this question. 

The RBOCs are not like any other company. Remember, 
they have millions of customers who have no choice but to 
pay what they charge. Wherever you live in the U.S., you 
have exactly one choice as to your local phone service, and 

that is whether to pay what the local monopoly charges you. 

They can't lose money— they're guaranteed a profit by the 

FCC and the PUCs. A company that ^_«,^^__^^ 

can't lose money is not a fair competi- 
tor to a company that can. 

The other reason they can't compete 

fairly is that they set the rates charged 

to their competitors, but don't pay 

them themselves. How would you like 

it if your competitors set your costs 

but didn't have to pay them? 

As Judge Greene says, it is 

inevitable that GEnie, Prodigy, 

CompuServe, Delphi, and whatever 

other information providers there are, 

will either be acquired or go out of 

business. Look at what's happened to 

the cellular telephone industry: All of 

the major cellular carriers are now 

owned by RBOCs. Has this resulted in 

lower prices, better quality or any 

other benefit to the consumer? In the 

words of the immortal Doug 

MacKenzie, "No way, eh!" 



The RBOCs have a history of providing poor service to 
their captive customers while at the same time tugging and 
poking at every restriction on them. Deregulating them is 
anticompetitive, anticonsumer, antidemocratic. If things 
continue to progress in this fashion, the RBOCs will soon 
control cable television, too. When they tell you you'll get 
better service and more choices, think about how much better 
and cheaper your local telephone service has gotten, and 
how many more companies you had to choose from. Don't 
blame it on the MFJ— the MFJ only split the greedy, 
monopolistic Bell System into seven greedy, monopolistic 
RBOCs. 

setjtnp and longjmp 

Ask any C programmer about setjmp and longjmp, and 
he's likely to mumble something along the line of "those are 
the functions you're not supposed to use or know about." 
But these are handy functions to have around. 

See Real/53, page 18 



Real Computing 

X-10 Revisited, Mach, Minix and Desqview/X 

By Rick Rodman 

[There are certain disadvantages to publishing a magazine after hours. An obvi- 
ous one is where you rush into town between business trips to get ready for press, 
hurry through paste up, run off to the printer and finally to the post office and then 
find out you dropped the second half of an article! Of course, no one will notice such 
a gaff, right? Right. My apologies to Rick, and to those who took the time to point 
out my error. Following is the Real Computing installment from last issue— in its 
entirety! — Ed.] 



X-10 Revisited 

In issue 48 I wrote glowingly of the 
X-10 Powerhouse computer interface, 
known as the CP-290, that "any X-10 
commands which come across the line 
are converted to status messages that 
the computer can see". Mike Morris 
writes: "I have a CP-290, and mine 



Rick Rodman works and plays with computers because he sees that they are the 
world's greatest machine, appliance, canvas and plaything. He has programmed mi- 
cros, minis and mainframes and loved them dl. In his basement full of aluminum 
boxes, wire-wrap boards, cables running here and there, and a few recognizable 
computers, he is somewhere between Leonardo da Vinci and Dr. Frankenstein. Rick 
can be reached via Usenet at uunetlvirtechlrickr or via 1200 bps raodem at 703-330- 
9049. 



does not produce these messages when 
I push a button on a manual control- 
ler." 

After some experimentation and 
consulting with the X-10 gurus at 
Home Control Concepts, I have to ad- 
mit Mike is right. The CP-290 does re- 
port to the computer when buttons are 
pressed on it itself, but it doesn't report 
codes that come over the wire. It is a 
send-only, unidirectional device. 

Actually, the plot's even thicker 
than that. Manual controllers, like the 
wall switch modules, don't send codes 
at all, they only receive them. There is 
no way for a central controller to know 
See Real/52, page 19 
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Real/ 53, from page 17 

One use of these functions is to implement coroutines, a 
language feature that C doesn't have but is usually available 
in Modula-2. As an example, consider the typical Mac/ 
Windows/PM program. It has to be written as a "message 
loop", bottom-up style, using messy state variables to keep 
track of what's happening at any given time. But by using 
coroutines, you can separate the message loop from the 
main program logic, which can then be written in 
conventional, more readable, "top-down" style. (The 
implementation is left as an exercise for the reader.) 

The setjmp function is supposed to keep enough state in- 
formation for a C program to be able to be restored to that 
state later. This means it must save the stack pointer, frame 
pointer, and all register variables. In most NS32 implementa- 
tions, registers R2 to R7 are used for register variables. The 
function is passed a ;>np_t'«/ variable, which must be of array 
type so that it is passed by reference (address). It cannot push 
things on the stack, because it must return with everything 
as it was. It returns an integer which is zero when the envi- 
ronment has been saved, or nonzero if it returned via 
longjmp. 

The longjmp function is passed a jmp_buf variable and an 
integer value, which should be nonzero. When you call it, it 
doesn't return. Instead, the state information in the jmpjbuf 
variable (whether it's valid or not) is loaded and execution 
continues by returning from the setjmp function again. 

The reason I became interested in these functions is the 
overwhelming complexity of even the simplest multitasking 
routines. Without an emulator, it could be simply impossible 
to debug them. However, with non-preemptive or "coopera- 
tive" multitasking, it is not necessary to be so concerned 
about the machine state, nor deal with the hardware on such 
an intimate level. So, by using the setjmp and longjmp calls, 
plus one additional call which imitates setjmp, the basics of 
Metal's kernel are being constructed from simple C calls. 
This kernel will be message-based internally, using int val- 
ues as messages. 

Presently, Metal 0.7 is available in an installation kit in- 
cluding all source files. To obtain a copy, simply send me 
sufficient formatted floppies for 1.4 megabytes in a reusable 
mailer with return postage, and I'll put it on them and send it 
back to you. 

C Sickness 

After upgrading my C compiler to 6.0, 1 spent literal hours 
tracking down long math problems. It seems that Microsoft, 
in version 6, is even more aggressive in truncating values to 
ints. Consider the following statement: 

long_variable = Ox40000L; long_varlable = long_variable » 1; 

In older versions, and in most C compilers, the value re- 
sulting would be Ox20000L. But not Microsoft C 6.0! You see, 
the shift count 1 is an int, giving them carte blanche to trun- 
cate the other side of the expression to an int too, causing the 
result to be zero. So, even though a shift count of more than 
16 bits is ridiculous, the shift count has to be changed to a 
long. Who asked for this? 

MlnixonthePC-532 

Loading the Minix system onto the PC-532 is a tedious 
process. You have to download each of several big files into 
RAM in the debugger, write it to an unused hard disk parti- 



tion, boot Minix, "neat" the partition into a file, decompress 
the file, then "tar x" the file. Just transferring the data takes a 
long time; even compressed, there's about two megabytes of 
data to transfer. 

So what's it like once the transferring is complete? How's 
the "feel" of the system? Well, Minix on the PC-532 is proba- 
bly best characterized as fast, but sparse. Only the barest 
minimum of necessary files are included with the archives. 
The remainder of sources can be transferred from another 
Minix system, or obtained from Internet archives if you have 
access, or from various mail servers. (A "mail server" is a file 
archive which works through E-mail. You send it a message 
like "index" or "send foobar.txt" and it sends you its index or 
the requested file as a mail message.) 

I've just discovered that I can't use the C compiler, 
because my system doesn't have an FPU. The compiler 
provided is Gnu C. A small Emacs clone called "xemacs" is 
provided; it's similar to, but not the same, as "elle", provided 
with Minix 1.5. Presently I'm running the 1.3 kernel. 
Probably by the time you read this, I'll have upgraded to the 
so-called "1.5 hybrid" kernel, which is a mixture of 1.3 and 
1.5, and hopefully I'll have a patched C compiler running as 
well. 

In other Minix news, many people have complained that 
the elvis vi clone included with Minix 1 .5 dies with an "alarm 
clock" message. (Should we capitalize "elvis"? It's named 
after a "pop singer", I think.) At any rate, the mystery of this 
message has been solved. It's related to the "keytime" func- 
tion for slow arrow keys on serial terminals. To disable the 
"keytime" and prevent the crash, use the command ":se 
kt=0", or create a file ".exrc" in your home directory and put 
a line "se kt=0" in it. 

The source for elle is not included with Minix 1.5, but the 
source to elvis and mined are. 

The US Robotics HST Dual-Standard Modem 

My BBS is now equipped with a US Robotics HST Dual- 
Standard modem, acquired through US Robotics' sysop pro- 
gram. This modem is capable of operating in V.32bis or in 
HST mode, both of which are capable of throughput up to 
14.4 kb/s. Further, it is equipped with V.42 data compression 
as well. Now we're talking fast! Feel free to call up and try it 
out, and make comments. 

Next time 

More on multitasking and the NS32. Also, I've been play- 
ing some more with my X-10 devices; and, 1 hope to have 
more to report on Metal and on Don Rowe's Kotekan oper- 
ating system. In the meantime, may your sizeof int's and 
your sizeof long's ever be equal. • 

Where to write or call 

BBS: 1 703 330 9049 

(evenings; 1200, 2400, 9600, or even higher!) 

Metal OS, c/o Richard Rodman 
8329 Ivy Glen Court 
Manassas, V A 22110 

Home Control Concepts 
9353-C Activity Road 
San Diego, CA 92126 
1-619-693-8887 
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whether a user has manually turr\ed a light on or not. 

There is another computer interface available, which is 
called the TW-523. This device has an optoisolated TTL-level 
interface which can be operated through parallel input and 
output bits. It's "dumber" than the CP-290— it has no battery 
backup or timers — but it's bi-directional: the computer can 
send or receive any X-10 code over the power lines. Remem- 
ber, the manual buttons on the wall switch units don't send 
any code. However, you can receive codes sent by other con- 
trollers or by motion detectors. 

If you're planning a system controlled by a dedicated 
computer, the TW-523 sounds like the way to go, It^s avail- 
able from Home Control Concepts for $30, It's also available 
as part of a Powerline Interface Kit for $69, which includes a 
C library and sample code as well as a cable for connection to 
a PC parallel or serial port, 

HCC also has available some wireless motion detectors. 
These detectors send an on-code when motion is detected, 
and an off-code when motion stops, through the same base 
unit used by the wireless hand control. Because they're wire- 
less, you can put them anywhere — out in the yard, garage, 
parapet, moat, wherever. Because they send a code, you can 
not only turn on a light or sprinkler system, you can also 
detect the code in your TW-523 and activate a voice synthe- 
sizer or camcorder, or switch speakers connected to the ste- 
reo, or anything else. 

Mike Morris suggests some neat applications for X-10: "1 
want to be able to turn on the sprinklers when the ground 
gets dry or if the burglar is leaving, but not the day after a 
rainstorm. 1 want to run the dishwasher after everybody goes 
to bed, then turn the water heater off but back on an hour 
before 1 get up. And divert the clothes dryer exhaust into the 
furnace air intake when appropriate so the furnace grabs the 
preheated humidified air." 

Mike also provided some "from the trenches" information 
on X-10: "The X-10 signal can have problems 'jumping' 
across the two halves of a 220 volt household circuit. 1 ended 
up acquiring a capacitor of the proper value, installing it in a 
220v plug and plugging it in. 'One of these days' I'll install 
the Leviton capacitor module in the main electrical panel, but 
for now, it works," 

He also points out that some X-10 lamp modules "forget" 
their brightness setting and will "creep" up or down over 
several hours, and suggests "refreshing" their settings peri- 
odically, (That'll also solve the problem of people using the 
manual buttons— and staying too long in the bathroom, too!) 
He points out that the CP-290 doesn't keep accurate time, 
losing about an hour per month. Mine has forgotten its house 
code a couple of times, "The battery compartment in the CP- 
290 does not have a barrier between the battery and the cir- 
cuit board. Mine leaked and ate away a few traces, which I 
repaired with a small soldering iron and 30 gauge wire." 

Not only X-10, but the whole field of home automation is 
booming in popularity these days. The CE Bus, a fully-bi- 
directional superset of X-10, is coming, I'll venture a guess 
that the reasons for this sudden interest are (a) the increase in 
crime, especially senseless violence and vandalism, (b) higher 
energy costs, and (c) it's inexpensive and loads of fun! 

Mach on the PC-532 

Carnegie-Mellon has released a "Micro-Kernel" for Mach 
which contains no AT&T code. If you have ftp access (which 



I don't), you can get it and play with it. It's called a "micro- 
kernel" because it includes no I/O or utilities. A "UX server" 
task, made apparently of pieces of Unix, is run to provide the 
missing capabilities. Some folks at the Helsinki University of 
Technology in Finland have been working on bringing it up 
on the PC-532. Recently, they reported that they have the 
kernel itself running. The Mach kernel is "small" — about a 
quarter of a megabyte. They are cross-compiling using the 
Gnu C compiler and tools. 

At the same time, reportedly, CMU has a number of 
people working on a "free" (non-AT&T) Unix emulator, and 
the Free Software Foundation (Gnu folks) are supposedly 
trying to work Mach into Gnu in some fashion. 

Later in the year, the PC-532 Mach will become a part of 
CMU's standard distribution. The Encore 32532 system is one 
of three "reference ports" provided with OSF-1, also. Hope- 
fully someone at National will notice that these are not fax 
machines, 

MInix 

In the meantime, patches have been developed for a 386 
version of Minix, under which the Gnu tools are used for 
software development. With all the "smallness" of Minix out 
of the way, it becomes reasonable to implement subsystems 
like TCP/IP and X Window under Minix, However, Andy 
Tanenbaum, the author of Minix, originally intended it as a 
tutorial operating system for classes, and he doesn't want tre- 
mendous increases in the complexity of the package. For this 
reason, it is unlikely that the 386 version will be available 
from Prentice-Hall, Instead, if you want to run 386 Minix, 
you will have to either obtain ftp access to Internet and spend 
hours transferring files so you can have the fun of trying to 
cobble the system together from a bunch of patches, after 
which you can have the joy of trying to debug it. Some call 
the result "Advanced Minix", 

The files you would need are supposedly as follows: 

12259 Dec 12 1991 pub/Minix/oz/mx386,tute,Z 

John NalL^s tutorial. 
3623]ul 11 1990pub/Minix/oz/mx386_l,l,01.Z 

patch to mx386. 
45155 ]un 15 1990 pub/Minix/oz/mx386_l.l.t,Z 

tar file with 386 patches. 
12063 ]un 14 1990 pub/ Minix /oz/bcc,tar,Z 

tar file with 386 C compiler front-end. 
121962 ]un 15 1990pub/Minix/oz/bccbinl6,tar,Z 

C compiler 16-bit binary. 
118254 Jun 15 1990 pub/Minix/oz/bccbin32,tar.Z 
C compiler 32-bit binary. 43492 Jun 15 1990 pub/ Minix /oz/ 
bcclib.tar.Z 

386 library sources. 
96151 Aug 14 1991 pub/ Minix /oz/cpp.tar,Z 

C preprocessor (optional?), 
30659 Nov 15 1991 pub/Minix/oz/cppmake,tar,Z 

Earl Chew's cppmake program. 

The Mars Hotel BBS in Maryland (1-301-277-9408) is sup- 
posed to have all these files. It also has a great deal of the 
comp,os,minix postings. For the moment, I've decided 
against bringing up 386 Minix, because I already have Minix 
with GCC on my PC-532. 

Minix 1,6 is being beta-tested by some people out there. 

See Real/52, page 8 
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Zed Fest '91 



Where Beer and BIOS Meet 



By Lee Bradley 



[Talk abounded at the '91 Trenton Computer Festival that 8-bitters should not wait a year to get together. It was decided to hold an affair 
in October. Lee Bradley, publisher 0/ Eight Bits & Change, took a leadership role. 1 asked Lee to fill us in on what transpired. In perfect 
North American style, we claim all "Zed-Vest's, " the festivals held in Germany as reported by fay Sage not withstanding!— Ed.] 



On October 18th, Ian Cottrell, his wife Nadine, daughter 
Jenny and son David headed south. John Anderson had sent 
his smoked YASBEC north a few days before to Paul 
Chidley; Paul put the smoke back in, for this is what is 
needed to repair anything smoked, according to Ian. Ian car- 
ried John's YASBEC with him. 

By the 19th, the Cottrells, John, the working YASBEC, Lee 
and Linda Bradley, Steve Dresser, Howard Goldstein and 
Sigurd Kimpel had converged on Walt and Linda Wheeler's 
home in Nassau, NY. The keys CMAZE were pressed by 
John on his YASBEC. Lee hit <retum>. 

Zed Fest '91 had begun. 

Others arrived. Jay Sage preceded Stephen Griswold by 
about an hour; Stephen entered the door muttering some- 
thing about the map. What really happened with Stephen 
and the Sandwich Crew (both Lindas, Nadine and kids) re- 
mains fuzzy but the Crew, the .sandwiches and Stephen 
uruted at about 3 PM, much to the relief of all. We later 
learned the delay was due to T-shirts reading "Our Next Hus- 
bands Will Be Normal." An unusual sandwich-making algo- 
rithm predating the Distributive Law added to the confusion: 
For Turkey = 1 to Turkeys_Ordered; Get_Roll; Dollup_of_ 
Mayo; Turkey_Slice; LettuceLeaf; Assemble; Wrap; 
Cleanup; Next Turkey. [Ed: Notice Cleanup is inside the loop?] 

Ian got Trenton '92 on the agenda. Jay took notes: April 11 
and 12 this year (eariy!). We'll set up a booth at the Flea 
Market and have people assigned time slots to man/ 
woman/computer it. Demos and talks will be intermixed in 
the lecture hall as well, but the emphasis will be outside. Call 
us if you want to help. We need Banners, Books, Brochures, 
BOOS', BIOS' and Bodies. 

We talked of having our own awards at our own banquet 
Saturday night. Why should everyone eat gray roast beef and 
be put to sleep by an acceptance speech when we can pick 
our own meal and our own winners? 

John Anderson's wife Judy joined us for dinner at the 
Four Brothers restaurant with the memorable quote: "John 
wants to build a CP/M LAN in our living room." The double 
anchovy pie eating contest was temporarily put on hold 
when anchovies were not found on the menu. Menus weren't 
a big thing for those present; we asked the waitress and 
found anchovies to be an undocumented topping. We or- 
dered. Ian entertained those near him with some great new 
jokes and repeated the best on for those out of earshot when 
we returned to the Wheelers'. 



Many of us descending into Walt's basement to call GEnie 
and join the 10 PM Saturday night CP/M conference. Chris 
McEwen, Brian Moore and John Anderson (who had gone 
home to Albany) were on. Chris asked for a write-up on Zed 
Fest. 

Sunday morning, after a run with Linda Wheeler, Stephen 
and Jay, we talked briefly of BYES and ZREMOTE. Ian men- 
tioned ZMD 2.0 possibilities and then we all watched a video 
of Walt flying a parachute-equipped ultra-light. Apple pies 
and Mexican dip materialized after a three hour session dur- 
ing which Jay, Howard, Stephen, Wait and I tried to bring 
Walt up to Z33 (almost made it but a Trantor/Osbomed sys- 
tem got us in the end — where were you, Daryl, when we 
need you?). 

Jay left around 3 PM. My wife and I took Howard and 
Steve home to New Haven and West Hartford, rolling in at 9 
PM. 

The photos will have to wait for next issue as black-and- 
white processing takes longer than color. All in all, it was a 
lot of fun! Sure hope we will see you at the next gathering!* 



Computers: A Kid's Perspective 
By David Cottrell, Ottawa ONT 

I have had many opportunities to attend computer 
events all the country. I was at Zed Fest (I am Canadian), 
the fair at Trenton, and Walt Wheeler's get-together in Al- 
bany because my father, Ian Cottrell, always promises me 
fun-filled vacations. 

Right. 

No offense, but my idea of a good time is not listening 
to people talk about PBBS, RAM, ROM, Megs and hard 
drives. I'm into Ultima, Pac-Man and Super Mario. On the 
bright side, I have made many good friends and have seen 
some nice cities. 

Maybe if I put my mind to it, I might learn what PBBS 
stands for and if $300 is a good price for a hard drive. Oh, 
well. I still enjoy computer shows and if you hear Ian 
Cottrell will be at a show, then you can almost count on 
my being there. Now, if only someone would tell me what 
Eight Bits and Change is supposed to mean....© 
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Z-System Corner 

Implementing a Keyboard Buffer Using the NZCOM Virtual BIOS 

By Jay Sage 



First Some Personal Comments 

Until I was 27 years old and met my wife, I had essentially 
never been out of the United States, and the same is true of 
my parents to this day. My whole family had the common 
American myopia that pictures the whole world as thinking 
and acting pretty much the same way we do. 

My wife, on the other hand, came from a very different 
background. She was bom in one country and spent several 
years living in a second before she came to the United States. 
Her father's history was similar. When my wife was bom, he 
was living in his fourth country, and today he lives in his 
sixth! 

It was not until our honeymoon that 1 made the dramatic 
step of leaving North America and setting foot on another 
continent. My life and outlook were irrevocably altered. A 
few years later when my employer offered me the 
opportunity to go to Japan and spend a year working at the 
Toshiba Central Research Laboratory, I jumped at the 
opportunity. It was a splendid year, and 1 loved Japan. The 
very different culture, however, helped me see my own 
culture in a way that was probably not possible without that 
experience. I came back with an enormously greater 
appreciation for what my own country offers, an 
appreciation that continues unabated. 

My wife, keenly aware of the importance of a world per- 
spective, wanted to get our children started early. She had 
the idea that, rather than simply visiting with her parents in 
Switzerland, we should take the opportunity to expose our 
children deeply to European culture by enrolling them in the 
public school there. (The school calendar in Europe is differ- 
ent, and our children can get in about six weeks of school 
after their school here ends.) 



Jay Sage has been an avid ZCPR proponent since the very first version appeared. 
He is best known as the author of the latest versions 3.3 and 3.4 of the ZCPR com- 
mand processor, his ARUNZ alias processor and ZFILER, a "point-and-shoot" shell. 

When Echelon announced its plan to set up a network of remote access computer 
systems to support ZCPR3, fay volunteered immediately. He has been running Z- 
Node #3 for more than five years and can be reached there electronically at 617-965- 
7259 (MABOS on PC Pursuit, 8796 on Starlink, pw=DDT). He can also be reached 
by voice at 617-965-3552 (between 11 p.m. and midnight is a good time to find him 
at home) or by mail at 1435 Centre Street, Newton Centre, MA 02159. fay is now 
the Z-System sysop for the GEnie CP/M Roundtable and can be contacted as 
fAY.SAGE via GEnie mail, or chatted with live at the Wednesday real-time confer- 
ences (10 p.m. Eastern time). 

In real life, fay is a physicist at MIT, where is tries to invent devices and circuits 
that use analog computation to solve problems in signal, image and information 
processing. His recent interests include artificial neural networks and supercon- 
ducting electronics. He can be reached at work via Internet as SAGE@LL.MIT.EDU. 



Since we preferred that the children learn a language 
more widely spoken than a Swiss dialect of German, we de- 
cided to rent a vacation house in the mountains of the nearby 
Black Forest in Germany. This is a wonderful place to spend 
a vacation, and the children learn the language that my 
wife's family has used since coming to the United States. Last 
summer was the sixth year, and I am always thrilled to hear 
the children talking comfortably with their German friends. 
Last summer, rather than sleep late and have us drive her to 
school, my 11-year-old daughter preferred to get up early 
enough to catch the school bus at 6:30 am (!) so that she 
could spend the time with her friends on the bus. 

Computer User Groups in Germany 

Now we come to the first of the connections between this 
story and my 7CJ column for this issue. In the first few years 
1 was in Europe, 1 tried very hard to promote Z-System there, 
but it was a very frustrating experience. I knew that MS-DOS 
computers had not yet made the same inroads that they had 
here and that even businesses were still using CP/M 
computers. However, in Germany and Switzerland, the 
culture apparently did not lend itself to the formation of user 
groups as in the United States (and England and Holland). 1 
was able to find a few individuals interested in 8-bit 
computing, but no user groups. Those individuals confirmed 
my impression; they, too, felt all alone. 

One year I traveled to Munich to visit a fellow owner of a 
BigBoard I computer. I learned of him when he wrote a letter 
to MicroCornucopia magazine. While in Munich, 1 wandered 
into computer stores, each time asking if they knew of any 
CP/M clubs in Germany. The answer was always no. 1 did 
find one salesman, Zvonimir Racic, who was interested 
enough to start one, but it did not last 
even to the next summer. I have had 
no further contact with him. 

Since I was having no luck search- 
ing for 8-bit enthusiasts in person, I 
decided to try another approach. With 
great effort (and help from my wife 
and a German colleague at work here), 
I composed a letter-to-the-editor in 
German to one of the major German 
hobbyist magazines. They never even 
acknowledged it. At that point I gave 
up trying. 



ZedFest Germany! 

Given those earlier experiences, you 
can imagine how excited I was this last 
summer to be at the first European Z- 
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System Festival. In the small town of Brackenheim, Germany, 
near Stuttgart, a small but growing group of 8-bit activists 
got together to make plans, to share viewpoints, and, most 
importantly, to meet each other face to face. 

It all started when Uwe Herczeg, at whose computer store 
in Brackenheim the meeting was held, decided to put a small 
ad in Computer Flohmarkt (Computer Fleamarket), a news- 
print magazine filled almost entirely with classified ads. His 
ad sought contact with any other CP/M computerists who 
might still be left in Germany. Amazingly, he received more 
than one hundred responses! Among them were the people 
at the ZedFest, who form the core of the CP/M activist com- 
munity in Germany today. 

The man I was most eager to meet was Helmut Jungkunz. 
1 no longer remember exactly how we first came into contact 
(maybe he will tell some stories some day here in TCJ ), but 
we had been in very active communication for over a year. 
Helmut is the 'nuclear reactor' that powers the 8-bit commu- 
nity in Germany. He introduced Z-System to Germany, is 
sysop of Z-Node #51 in Munich, is the only Z-System dealer 
in Europe, and heads the Schneider/Amstrad CPC User 
Group. If only I had run into Helmut years before when 1 
was in Munich! 

Also at ZedFest Germany was Tilmann Reh, whose ar- 
ticles on the Z280-based CPU280 computer you have seen in 
this and the previous issue of TCJ. I had communicated with 
him several times over the Internet, and I was eager to meet 
him. He traveled to the meeting by motorcycle and was quite 



a sight in his sleek, black leather riding outfit and space-age 
helmet. 

Tilmann brought along a CPU280 card to show me. It was 
hard to believe that such a powerful computer could fit on 
such a tiny card! Of greater interest to others at the meeting 
(they were almost all using the CPU280 already!) was the 
prototype he brought of the IDE disk controller for use with 
the CPU280. Uwe Herczeg was working on the software to 
integrate it into the system. 

Others present were as follows: Fritz Chwolka, head of 
Club 80 in Aachen, on the western border of Germany near 
Belgium and Holland; Herbert Oppmann, member of the 
MTX User Group, which now supports ZCPR33 for the MTX 
computers; Andreas Kisslinger, also from Munich, well at 
home with several operating systems, and an expert Z80 pro- 
grammer; and Guenther Schock, a hardware expert whose 
projects, such as an LCD terminal and a CP/M-Plus laptop 
computer, we may soon read about in TCJ. 

Finally, I was especially flattered by two hobbyists who 
came from very far away to meet me. Juergen Peters, a main- 
frame hardware engineer by profession, drove down from 
Hamburg in the far north of Germany. Franz Moessl's trip 
seemed the most impressive, even though the actual distance 
was considerably less than from Hamburg. He came all the 
way from Italy, where he lives in 8-bit isolation in the Tirol, a 
part of northern Italy adjacent to Austria. 

For two days, we all had a wonderful time talking com- 
puters and socializing (and, of course, drinking beer!). Dur- 



Listing 1. The code needed to implement the keyboard 
buffer in the NZCOM virtual BIOS. 

; Everything is standard in the KEYBIOS, even the opening 
; jump table 

; Cold boot 



START: 


JP 


BOOT 


WBOOTE: 


JP 


VJBOOT 




JP 


CONST 




JP 


CONIN 




JP 


CONOUT 




JP 


LIST 




JP 


PUNCH 




JP 


READER 



; ... standard VBIOS code omitted here 

; Vte make a small change in the auxiliary lOP jumps. The 
; console status (CONST) and console input (CONIN) entries 
; jun^ to our new code. 



Jump to extended routine 
Jump to extended routine 



AUXJMP: 
CONST: 


JP 


KCONST 


CONIN: 


JP 


KCONIN 


CONOUT: 


JP 


ICONOT 


LIST: 


JP 


ILIST 


PUNCH: 


JP 


IPUNCH 


READER: 


JP 


IREADR 


LISTST: 


JP 


ILSTST 



; End of Header.... The following code is free-form and 
; may be moved around if necessary. 



The new code for the keyboard buffer is inserted right 
after the auxilliary jump table. It starts with an 
identifying signature. Then comes the actual keyln 
buffer followed by the new code. The buffer starts with a 
word that points to the next character to fetch, if any. 
The pointer is initialized to the start of the buffer, 
which is initialized to a null to indicate the end of the 
buffer's contents. 



; The following equate defines the number of actual 
; characters that the keyboard input buffer can hold, 
; exclusive of the terminating null and the header 
; information. 



kbufsize 


equ 6 




db 


'KEYIN' 


; Signature 


db 


kbufsize 


; Length of buffer 


keyptr; dw 


keybuf 


; Pointer to next char 


keybuf: ds 


kbufsize, 


; Fill with nulls 


db 





; Terminating null 



Subroutine to fetch the next key from the keyboard buffer 
and set zero flag if no character. HL is left pointing 
to the pointer to the next character. 



ktest: 


Id 


hi, (keyptr) 


; Get ptr to next char 




Id 


a, (hi) 


; Get the character 




or 


a 


; Test for null 




ret 







Extended console status code. It checks the keyboard 
buffer and returns true if there is a character in the 
buffer. Otherwise it passes the call on to the CBIOS. 



kconst: call 

JP 
Id 



ktest 
z , iconst 
a,Offh 



Test for key in buffer 
If none, call BIOS 
Otherwise return FF 



Extended console input code. If there is a character in 
the keyboard buffer, then it is returned and the pointer 
is advanced. Otherwise the CBIOS is called. 



Test for key in buffer 
If none, call BIOS 
Increment pointer 
Save it 
Return with key in A 



the rest of the stardard VBIOS code follows 



kconin: 


call 


ktest 




JP 


z,iconin 




inc 


hi 




Id 


(keyptr), hi 




ret 
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ing one of the discussions 1 was told about an important 
issue that constitutes the second connection between comput- 
ers and my personal comments earlier. 

Programming for Compatibility— Again! 

In my previous column I talked about making Z-System 
programs compatible — or at least tolerant — of vanilla CP/M. 
Ideally, Z-System programs would work to the extent 
possible in whatever environment they found themselves; at 
the least they would terminate in a graceful manner. It is too 
early to tell how responsive the community will be to my 
message, but the initial indications are very positive. Howard 
Goldstein, after proofreading the draft of my column, 
immediately fixed up LPUT and LBREXT. As soon as Rob 
Friefeld received and read my column, he started to look at 
his programs. 

There is a second issue in programming for compatibility, 
and that is programming for compatibility in culture and 
language. For years, we in the United States have been writ- 
ing our programs with only our own keyboards, our own 
screens, and our own language in mind. We did not do this 
out of disrespect or deliberate disregard; we did it because 
nothing made us think of a more cosmopolitan picture. In 
our experience, only Americans were using Z-System. That 
has now changed, and we need to change. 

I won't be able to cover all the implications of this here. 
For one thing, 1 do not yet know myself what all the 
implications are. We will need to communicate with and 



Listing 2. Rudimentary version of the KEYIN utility for 
filling the keyboard buffer in KEYBIOS. 



; Program: 
; Author: 
: Date: 



KEYIN 
Jay Sage 
October 1, 1991 



; This program manages the keyboard inbut buffer in the 
; special version of the NZCOM virtual BIOS called KEYBIOS. 
; It interprets the command tail and adds the indicated 
; input to the keyboard buffer (if it fits). 



sigoff equ 

cr equ 

If equ 

bell equ 

tab equ 



97H 

Odh 
Oah 
07h 
09h 



; Offset to signature 



; Library routines 

extrn z3init, eprint 
keyin: 



jp 
db 
db 
dw 
dw 



start 

'Z3ENV' 

1 



keyin 



; Filled in by ZCPR33+ 
; For type- 4 version 



; Target signature that identifies KEYBIOS. 



sign: db 
nsign equ 

; Signon message 

signon: 



'KEYIN' 
S - sign 



KEYBIOS signature string 
Length of signature 



call eprint 

db 'KEYIN, version 1.1 (10/01/91)' 

db cr,lf 

db 

ret 



learn from others in the world who are using and developing 
8-bit computers. 

There are two issues that I will mention here. The most 
important one is the use of special characters. In the United 
States, we are quite accustomed to using various special char- 
acters, often for pseudo-graphics. For example, we may use 
the verticule (vertical bar) character (ASCII 7C) as a separa- 
tor. Most European languages (and probably non-European 
languages, too) have characters with accents, and these are 
represented by the ASCII codes for special characters. In Ger- 
many, for example, the following associations are apparently 
used: 

[ upper case A with umlaut 

\ upper case O with umlaut 

] upper case U with umlaut 

{ lower case a with umlaut 

I lower case o with umlaut 

} lower case u with umlaut 

When we include those characters in our programs, the 
screen displays in Europe (and Canada, for that matter) are 
often not pleasant. 

The second issue concerns language. For example, pro- 
grammers in the United States generally assume that yes/ no 
questions will be answered with 'Y' or 'N'. In Germany, 
however, it would be nicer if ']' (for 'ja') and 'N' (for 'nein') 
could be used. In France it would be 'O' (for 'oui') and 'N' 



; Show help message. 

help: 

call eprint 

db ' Syntax: KEYIN string' ,cr, If 

db 

ret 

; We get here if the signature is not right. Report problem 
; to user and terminate. 

badbios : 

call eprint 

db ' KEYBIOS not present 1 ' ,cr, If 

db 

ret 

start: 

; Initialize environment 

Id hl,(env) 
call Z3init 

; Display signon message 

call signon 

; See if there is a command tail. 



Id 
Id 
or 



hl,80h 
a, (hi) 
a 
z,help 



; Point to tail buffer 

; Get count 

; Test for zero 

; If zero, show help screen 



; Make sure that the KEYBIOS is running by checking for the 
; s ignature . 

Id hl,(l) ; Get warmboot address 

Id de,sigoff-3 ; Offset to signature from 

; . .warmboot entry 
add hl,de 
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(for 'non'). We also, of course, display all screen information, 
including prompts, in English. 

Is there anything we can do to be more accommodating in 
these matters? I'm not sure about the whole solution, but I 
have some ideas. For yes/no questions, we could allow for 
all common language possibilities: 'Y', ']', 'O', and 'S' for the 
affirmative, for example (do we need anything other than 'N' 
for the negative?). Another possibility is that we include a 
language configuration screen with the ZCNFG CFG file pro- 
vided with programs. Simple language changes, such as the 
letters used for yes and no and the characters used for special 
functions, could be changed using this screen. ZCNFG might 
be able to handle more significant text items for programs 
with little text output. 

When a program provides a lot of text output to the 
screen, there may be too many changes to handle with 
ZCNFG, and we might have to go back to the old overlay 
method of configuration. Our programs could come with 
source code for language overlays. Authors with skills in 
other languages might even take a stab at providing some of 
these overlays themselves. Otherwise, native speakers in 



various countries could provide the overlays. 

To make it easier to use such overlays, one would want to 
collect all the messages that a program uses in one area 
rather than scattering them throughout the program as we 
generally do today. Rather than using SYSLIB routines like 
PRINT that display characters provided in-line in the code, 
we should use routines like PSTR that display characters 
pointed to by a register pair. Such source code is not as 
convenient to read, but it would make patching much easier 
(and it makes debugging easier, too). Another small detail 
would be to provide some extra spacing between message 
strings in case a message in another language is longer. 
Except in very rare instances, the slightly longer code that 
results from this approach will not be an undue burden. 

NewZ-Nodes 

Before turning to the main technical subject, I would like 
to announce four new Z-Nodes that joined in the past two 
months. Dave Chapman in Victoria, British Columbia (604- 
380-0007), and Terry Bendell in CoUingwood, Ontario (705- 
444-9234) are our two new nodes in Canada. Ewen McNeill 



sigtesti 



Id 


de , sign 


; Point to signature 


Id 


b,nsign 


; Length of signature 


Id 


a,(de) 




cp 


(hi) 




:r 


nz,badbios 


; Jump if no match 


ino 


hi 


; Bump pointers 


inc 


de 




djnz 


sigtest 


; Test whole signature 


are 


ready for the real 


task 


Id 


a, (hi) 


; Save the size of 


Id 


(kbufsize) ,a 


; . . the keyboard buffer 


inc 


hi 


; Point to pointer 


Id 


(kptradr), hi 


; Save its address 


Id 


e,(hl) 


; Get its value into DE 


inc 


hi 




Id 


d,(hl) 




inc 


hi 


; Point to start of buffer 


Id 


(keybuf), hi 


; Save the address 


Id 


hi, buffer 


; Point to working buffer 


Id 


bc,0 


; Initialize count 



Copy any remaining contents of keyboard buffer to working 
buffer 



copyl : 



Id 



a,(de) 



Id 


(hi), a 


or 


a 


jr 


z , copy2 


inc 


de 


inc 


hi 


inc 


c 


jr 


copyl 



Get next character from 

. .key buffer 

Write to working buffer 

Set flag 

If null, break out of loop 

Otherwise bump pointers 

; Increment count 

; Loop back for next char 



; Now we have to add the new characters from the command 
; line. HL still points to working buffer. This code needs 
; to be extended with the full functionality of ECH0.COM so 
; that control characters and other special characters (such 
; as semicolons) can be entered. 



copy2 : 



copy2a: 



Id 



de,82h 



Id 


a,(de) 


Id 


(hi), a 


or 


a 



; Point to second char (if 
; ..any) in command tail 

; Get the character 

; Store it in working buffer 

; Set flag 



If null, we're done 
Otherwise, bump pointers 

Increment the count 
If we reach zero, 
. .definitely too many 
Else loop back for more 



Now we have to copy the contents of the work buffer back 
into the keyboard input buffer. 



jr 


z,fillkey 


inc 


de ; 


inc 


hi 


inc 


C ; 


jr 


z, overflow ; 


jr 


copyZa ; 



fillkey: 



Id 


a, (kbufsize) 


cp 


c 


]r 


c, overflow 


Id 


de, (keybuf) 


Id 


hi , ( kptradr ) 


Id 


(hl),e 


inc 


hi 


Id 


(hl),d 


Id 


hi, buffer 


inc 


be 


Idir 




ret 





; Make sure there is room 

; Too many characters 

; Get start of buffer 

; Address of pointer 

; Set pointer to beginning 



; Point to working buffer 
; Adjust counter to include 
; ..trailing null 
; Copy it all 
; We ' re done 



We get here if the keyboard buffer is too small to hold 
all the characters. For the moment we just give a message, 
but the code should call the error handler if possible. If 
there is no error handler, then the MCL should probably be 
cleared. 



overflow: 












call 

db 

db 

db 

db 


eprint 
'Too many 
' keyboard 
cr,lf 



characters for 
input buffer. ' 




ret 












; Data items 












dseg 












kbufsize: 
kptradr : 
keybuf: 
buffer: 


ds 
ds 
ds 
ds 


1 
2 
2 
257 


; Size of 
; Address 
; Address 
; Working 


keyboard buffer 
of next-char ptr 
of beg of buffer 
buffer 
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has established the first Z-Node in New Zealand. His node is 
running, I believe, on a mainframe computer. Those who call 
in at 64-4-389-5478 in Wellington will learn about other ways 
to connect to the system. Finally, we also have a new node in 
the United States. The Kaypro Club of St. Louis has turned its 
system, run by sysop Bob Rosenfeld, into a Z-Node. It can be 
reached at 314-821-0638 on the MOSLO/24 outdiaJ of PC- 
Pursuit. Give these new nodes a call and welcome them to 
our ranks. 

An NZCOM Virtual BIOS Keyboard Buffer 

Z-System's extended batch processor, ZEX, is a very pow- 
erful tool with many fascinating and effective uses. Like 
SUBMIT or the MS-DOS batch facility, it can carry out a 
sequence of commands. However, if this is all one needs, 
then alias scripts should almost always be used instead, since 
they impose no additional system overhead. 

ZEX, because of all the powerful features it provides, 
takes up quite a lot of memory. 1 just ran the utility 
TPA.COM on my system. Invoked from the command line, it 
reported a TPA of 51.5K; running it under ZEX gave a figure 
of 47.5K. Thus ZEX cost 4K of memory: 2K for its own code 
and 2K because its RSX (resident system extension) locked in 
the 2K command processor. 

The situation where ZEX has been indispensable is when 
one wants a script not only to invoke commands but also to 
provide 'interactive' input to a program. If programs can 
accept input on the command line, then an alias script can 
handle the situation, but many programs take their input 
only interactively. 

Once ZEX is loaded, it remains in memory until all com- 
mands in its script have been totally completed. There have 
been numerous occasions when I have wanted to feed just a 
short string of characters to a program before 1 proceed 
manually. In such a case, I really hated to suffer the memory 
penalty of ZEX to accomplish this. In some cases, such as 
with my database manager, the program would not be able 
to run with ZEX in place. 

The solution I present here provides yet another example 
of the power of the NZCOM virtual BIOS. I simply added a 
little code to my normal virtual BIOS to implement a key- 
board buffer, and then I wrote a utility to fill that buffer. The 
BIOS 1 called KEYBIOS; the utility I called KEYIN. A typical 
command line (probably in an alias) would look like: 

KEYIN string for program; PROGRAM 

KEYIN fills the keyboard buffer. Then, when PROGRAM 
runs and requests user input, the KEYBIOS sees characters in 
the buffer and returns them to the program. How this works 
will be clearer after you see the code for KEYBIOS. 

KEYBIOS 

The new code contained in the virtual BIOS to support the 
keyboard buffer is shown in Listing 1. Here is what the code 
has to accomplish. When a program calls the BIOS to get a 
character, the virtual BIOS must first look in the keyboard 
buffer. If it finds a character there, then it returns that charac- 
ter and sets its pointer to the next character. If the keyboard 
buffer is empty, then the code simply passes the job on to the 
real BIOS, which will return a character actually typed at the 
keyboard. 

One complication is that the BIOS also supports a function 



(called console status) that asks if there is a character ready 
without actually fetching it. We have to fake out that call, 
too. We follow a similar strategy. We first look in the key- 
board buffer. If there is a character there, then we report back 
that a character is ready. If there is no character in the buffer, 
then we pass the job on to the console status routine in the 
real BIOS. It is amazingly simple! 

How do we do all this? Well, I think the code in Listing 1, 
with all its comments, is fairly clear. There are j ast a couple 
of things I would like to elaborate on. 

The code includes two items that are not actually needed 
by KEYBIOS for its functioning. First, the code includes a 
signature string, 'KEYIN', at an established location. This 
allows a utility, such as the KEYIN.COM program that we 
will discuss in more detail shortly, to determine that the 
appropriate VBIOS is present. Following the signature string 
is a byte containing the length of the buffer. KEY1N.COM 
needs this to know how much space is available in the buffer. 
Without this information, it might overfill the buffer and 
clobber code. 

The implementation of the buffer itself is much like the 
multiple command line in ZCPR3. At the beginning of the 
buffer there is a word that contains the address of the next 
character available from the buffer. A null character (ASCII 
value zero) is used to indicate the end of the buffer. 

The KEYIN Utility 

Listing 2 shows a very rudimentary version of the KEYIN 
utility that is used to add characters to the keyboard buffer in 
KEYBIOS. Again, the listing with its comments is largely self- 
explanatory, and I will elaborate on only a few issues. 

First, in view of my earlier discussion, I am embarrassed 
that this code does not have the facilities for language invari- 
ance that I recommended. 1 was tempted to put them in for 
the listing, but 1 decided that there would be too much risk of 
introducing an error. Before releasing the full version of the 
utility, I certainly will follow my own advice. 

The code does try to be quite rigorous. Once the program 
has displayed it signon message, it checks to see if any data 
has been passed on the command line. If there is none, a 
syntax message is displayed and the program terminates. In 
the final version, the code should check for the standard Z- 
System help request "/ /" in the command tail. 

Next, the code looks for the signature string at the proper 
offset in the BIOS. If it does not find it, then an appropriate 
message is displayed and execution terminates. Otherwise, 
various information from the buffer header is fetched and 
stored for later use. 

There may be characters already in the buffer, and KEYIN 
is designed to retain them and to append any new input. In 
the final version, one might want an option switch to flush 
any characters that remain in the buffer. To make the work 
easier, a temporary buffer in KEYIN is used to form the new 
contents for the keyboard buffer. Therefore, we start out by 
copying anything in the key buffer to the working buffer. 

Next we append characters from the command tail. In the 
final version of KEYIN, the code should include all the spe- 
cial string interpretation techniques used in ECH0.COM so 
that control characters and other special characters that can- 
not be entered directly in the command tail (such as semico- 
lons) can be included. 

Since the structure of KEYBIOS is such that the buffer can 
never be longer than 255 characters, we monitor the number 
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of characters in the working buffer and abort if the count 
exceeds that value. Once the working buffer is completely 
filled, then we check the actual character account against the 
actual size of the keyboard buffer. If all the characters will fit, 
we move them into the buffer and set the pointer to the 
beginning of the buffer. KEYIN can then return control to the 
command processor. 

If the characters will not all fit in the buffer, then we have 
to do something else. In the simple version in Listing 2, the 
program simply gives an error message and aborts. This 
leaves the key buffer unchanged. In a fully developed ver- 
sion of KEYIN, the error handler should be called so that the 
user can decide how to deal with the problem. If no error 
handler is available, then we have a more difficult problem. 
One course of action would be to clear the key buffer and 
flush the entire command line buffer (and terminate ZEX if it 
is running). Another possibility might be to clear the key 
buffer but allow the subsequent commands in the command 
line buffer (or ZEX) to run. The user would then have to do 
manually what KEYIN was trying to care of for the user. 

Very Important Caveats 

As it turns out, dealing with characters at the BIOS level, 
as we do with KEYBIOS, involves some troublesome issues. 
When I first got KEYBIOS running, I was surprised that I 
always lost the first character that I put into the buffer. That 
missing character then appeared the next time the command 
processor prompt appeared. Many of you have probably 
seen a mysterious character like this, and you may have rec- 
ognized it as something you typed earlier that was ignored. 

It is beyond the scope of this article to deal with this issue 
fully. Basically, it derives from a fundamental flaw in the 
design of CP/M. As we have seen, CP/M has a function to 
get a character from the BIOS and to ask the BIOS if a charac- 
ter is ready. But there is no way to ask what the character is 



without actually fetching it. 

Why is that a problem? Well, the disk operating system 
(BDOS or equivalent) often provides special processing when 
the characters control-C, control-S, or control-P are pressed. 
Unfortunately, as we just noted, it has no way of finding out 
if one of those characters has been pressed without reading 
the next character. If the character turns out to be one of the 
three special ones, all is well; it processes the character. 

But what if it is some other character. The BDOS would 
really like to say, "so sorry, not for me" and put the character 
back for the application program to read it. But it can't do 
that. So it does the next best thing. It puts it into a special 
buffer in the BDOS, and the BDOS plays the same kind of 
trick that we do in KEYBIOS. When a program asks for a 
character, BDOS first checks its special one-character buffer. 

When programs perform all their character I/O using the 
BDOS or all of their I/O using the BIOS, then things will 
work reasonably well. However, if calls to the BDOS and 
BIOS are mixed, then characters can get lost in the BDOS 
buffer only to appear later when not wanted. 

Every time I tried using KEYIN, I found that the com- 
mand processor swallowed a character when it took control 
after KEYIN was finished. The pragmatic solution was to 
include a backspace character as the first one in the keyboard 
buffer, since the command processor would ignore it. 

There are some other issues that KEYBIOS does not ad- 
dress. For example, some programs begin by flushing charac- 
ters from the BIOS. Here is how they do it. They call CONST, 
and if there is a character they read it. This is repeated until 
CONST reports that no characters remain. Such a program 
will completely defeat KEYIN/KEYBIOS. Joe Wright has ad- 
dressed these issues very carefully and cleverly in his lOPs 
(such as NuKey). KEYBIOS, however, is meant to be a very 
simple, minimal-memory solution, and it seems to do the job 
in my applications.© 



Editor, from page 2 

months. After all these years of reaching around the world 
with my computer, I guess I assumed everyone was doing it. 
This turns out to be a false assumption. 

CP/M users seem particularly confounded by the Internet. 
There were no good tools in CP/M to use the net until last 
year. I have been hoping for an article on using David 
Goodenough's UUCP tools. Nothing has come up so far. 
We've drawn another blank with Fido compatible CP/M bul- 
letin board systems, though there are at least three out there. 
Consider this a Call for Papers on telecommunications. 

On Today's Menu: 

We had a short article in the last issue on a Z280 based 
system from Germany. The information was so new then that 
I did not even have a return address to the author! Tilmann 
Reh returns with more for us. This doesn't take away from 
the YASBEC, but it does prove an adage. When it rains, it 
pours. These two systems come after a drought of several 
years in CP/M hardware development. 

Wayne Sung presents an interesting way to wire a large 
LAN with very low cabling costs — piggyback on your in- 
house cable television system. Of course, this presumes you 
have found a need to install a cable television system. Don't 



be too quick to scoff the idea, though. University campuses 
are wired and the technology is transferable. Could this idea 
be expanded to community-wide networking over commer- 
cial CATV? Think about it while you read Wayne's article. 

Jan Hofland returns with his Arbilrarxj YJaveform Generator, 
discussing the software at greater length. You will recall that 
we had the schematics for this project last issue. We will 
finish the series next time with the last of his source code. Jan 
built this system to provide a test bed for structural testing, 
and used the Harris RTX2001 and EBForth. This is the kind of 
article I enjoy. Not your common everyday project! 

Terry Hazen completes his topic on lOPs while Al 
Hawley continues with Getting Started in Assembly Language, 
discussing functions with structured programming. Both 
have proven to be very popular topics. 

I would like to welcome Lee Bradley to our pages. He 
reports on the Zed-Fest held in Nassau, NY. Lee publishes 
Eight Bits & Change, which we have mentiojied several times 
in the past. You will enjoy his humor. I always like to take a 
break when Lee's articles come in. 

It seems that Rcader-to-Reader struck a popular chord. We 
have received a number of good letters. The direction this 
publication takes is given by you, and I always look forward 
to your feedback as do the authors. I will try to include as 

See Editor, page 45 
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Getting Started in Assembly Language 

Implementing Functions with Structured Programming 



ByA.E. Hawley 



In Assembly Language Programming, part 3, we discussed 
program structure, using ZCNFG as an example. While writ- 
ing that article, 1 realized that there was considerable room 
for improvement in ZCNFG itself. Version 18 was released 
soon thereafter, followed by version 19. ZCNFG19 contains a 
major enhancement: the ability to extract its CFG files from a 
LBR type library. I hope that you were able to use the latest 
version in conjunction with that article. We will continue to 
use ZCNFG19 to illustrate this month's subject. Along the 
way, we'll encounter a solution to a coding problem that 
may surprise you. The problem: to write a block of assembly 
code that sets a flag (Z, for example) if A contains a byte 
which is either or contains exactly 1 set bit. Try your hand 
at this before before finishing this article. You may be sur- 
prised at the solution. 

Functions in ZCNFG 

When ZCNFG is running, the user selects a configuration 
item from a menu by typing its identifier. If data is required, 
he is asked for it on a prompt line. The screen is then 
updated to show the new configuration. This process is re- 
peated indefinitely until the user selects an item that causes 
the program to terminate. This flow of data is illustrated in 
Figure I. Data input from KEYED (the user) to the SETOPT 
routine is used to select a record from the current case table. 
SETOPT uses that record to select the function FN (=lN_FNn 
& LD_FNn) to execute. FN uses data contained in the case 
table record to modify the configuration block. SETOPT is an 
infinite loop! Tigure 1 only shows data flow for configuration 
items. A second case table, internal to ZCNFG, is always 
effectively appended to the one from the CFG file. That table, 
a fixed part of ZCNFG, contains the pointers and data 
required to change menus, display help screens, and exit 
from the program. The SETOPT and MCASE routines 
together are an implementation of a Finite State Machine. 

ZCNFG performs 9 distinct configuration functions, 
FN0...FN8. Each FN is implemented as a subroutine with two 
entry points, IN_FNx and LDFNx, where x is 0...8. As 
shown in Figure I, lN_FNx transfers data into the CFG block 



with any translation required. LDFNx transfers data from 
the CFG block to the Menu Screen Image in memory, again 
with any translation required to convert back to printable 
text. For example, FN 8 toggles a byte between the values of 
and OFFH in the CFG block and between a pair of strings 
(like YES and NO) on the screen. The entry points for the 
Functions are listed in a table (FNTBLE:) in the order of their 
number. New Functions can be added to ZCNFG by writing 
the code and adding the new entry points to the table. 

To summarize, each Configuration Function has two basic 
tasks: 

1. IN_FNx updates configuration block data, requesting 
additional input from the user if required. 

2. LD FNx updates the screen image from data in the con- 
figuration page. 



Figure 1, CONFIGURATION DATA FLOW IN ZCNFG 

KEY — > (SETOPT) < [MENU LIST, CASE TABLE] 



* — > 
♦< — 



(IN_FNx) 

/ 

+ + 

I copy OF TGT I 
I PGM CFG BLOCK I 
+ + 



< [CASE TABLE RECORD x] 



< — (INIT) 
— (EXIT) - 



H + 

I TGT PGM I 
I CFG PAGE I 
+ + 



(LD_FNx) 
\ 



< [CASE TABLE RECORD x] 
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CRT < — [SCREEN IMAGE] < — * 

NOTES: 

1. [ ] indicates parts of the CFG file in memory. 

2. ( ) indicates routines in ZCNFG that process data. 

3. Some functions require keyboard input to IN_FNx. 



In both cases, error handling code may be needed to de- 
tect inappropriate values and take suitable action. 

In ZCNFG19, FN7 has been rewritten. FN7 in eariier 
versions rotated a bit in the 3 Isb positions of a byte, leaving 
bits 3-7 unchanged. The new FN7 is 
superset of the old, rotating a bit in an 
arbitrary field of bits in a byte. In the 
following paragraphs we will examine 
this new code in detail to illustrate this 
structured approach to programming. 



Function Environment 

In order to write a Function, all of 
the data sources and destinations 
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required by the function must be defined. In addition, there 
must be provision for error handling if error conditions can 
occur. 

A function is invoked under two circumstances. The first 
occurs w?hen the user selects a menu item to change; the 
MCASE routine transfers control to the appropriate IN_FNx 
entry. After performing its task lN_FNx transfers control to 
LDFNx. The second occurs when ZCNFG is first invoked; 
the initialization routine MAPPER invokes LD_FNx for every 
configurable item in the CFG file to make screen image fields 
reflect the current configuration of the target file. 

MCASE and MAPPER both perform a housekeeping task 
whose main purpose is to make functions easy to write in a 
standardized manner. They transfer the parameters from the 
selected Case Table Record to a standard 7 byte data 
structure at OFFSET: whenever a new configuration item is 
selected. The data structure is shown in Listing 1. The 
meaning and use of the byte at CFGD depends on the 
function being performed. For FN7, this byte is a mask which 
defines the sequence of bits (a field) in a target byte that is to 
be processed. Usage of CFGD and SLIST are fully described 
for each FN in the documentation distributed with ZCNFG. 

There are two kinds of errors possible in most programs: 
recoverable errors and fatal errors. In ZCNFG recoverable 
errors are such things as user input which specifies an unim- 
plemented menu choice or an input value which exceeds an 
allowed range. When a routine encounters a non-fatal error it 
simply returns without changing anything. 

A typical fatal error occurs when the data in a newly 
loaded CFG file is not consistent with data in the target pro- 
grams configuration block. This could happen if the wrong 
CFG file had been specified on the command line or during 
development of a new CFG file. For fatal errors, ZCNFG 
contair^ a list of error message exits, each of which prints an 
error message and terminates ZCNFG by jumping to a com- 
mon entry in the main EXIT routine which leaves the target 
program unaltered. These fatal error exits are grouped to- 
gether near the end of the ZCNFG source module. 

The data structure at OFFSET, the fatal error exits, and the 
standardized convention for the Carry Flag comprise the En- 
vironment within which a function executes. Note that the 



definition of environment is in terms of DATA passed to and 
from the function. Service subroutines like MADC from 
SYSLIB which sends a byte to the screen in DECIMAL radix, 
are logically part of the function, not of the environment. 

A Typical Function 

Listing 2 shows the code for the new FN7. This function 
rotates a bit from right to left in the configured byte. The 
movement is restricted to a series of bits defined by the mask. 
Thus, if the mask is 01111000, successive invocations of FN7 



Listing 


1. 


Data 


Structure Used by ZCNFG Functions 


OFFSET: 


DS 




2 


; address of configuration data 


CFGD: 


DS 




1 


;data byte for current function 


S ftDDR: 


DS 




2 


(•address of current screen field 


S_LIST: 


DS 




2 


; address of string list or 
;min/max data for current function. 



might yield xOQOlxxx, xOOlOxxx, xOlOOxxx, xlOOOxxx, 
xOOOlxxx, etc. The x positions in the byte are not affected; 
they could contain other configuration data bits. The four bits 
that are affected might be tested in the target program to, for 
example, select one of four routines that display a date in 4 
different ways. In this example ZCNFG requires (in the CFG 
file) a list of four strings to display on the screen because the 
field contains four bit positions. Each string would describe 
one of the four date formats. 

An algorithm is a set of instructions for performing a 
computational task. It is usually stated in a high level lan- 
guage so that it is independent of the exact coding techniques 
of the implementation language. For fairly simple tasks, a set 
of instructions in English is adequate. For more complex 
computations, a pseudo-HLL language is more appropriate. 
Such algorithms may look like an inexact version of C or 
Pascal. I generally start a no trivial coding project with an 
algorithm like those shown below, making comments out of 
the steps and filling in source code after each step. 

The following algorithm was used for writing IN_FN7. 

1 . Use the Mask to isolate the bit field. 



Listing 2. A typical ZCNFG function 

FUNCTION 7 
ROTATE A BIT WITHIN A FIELD IN A BYTE 
entry points: IN_FN7 for user update 

LD_FN7 for initial screen load 
The following data structure has been filled in from 
the current record in a Case Table from the CFG file 
(OFFSET:) = address of cfg data byte 
(CFGD: ) = mask defining the field 
(S_ADDR:) = address of screen image field 
(S_LIST:) = address of list of strings 

IN_FN7: 

Rotate the bit field in the configuration block. 

exit- byte at (OFFSET:) contains rotated field. 
Screen image is updated with a string 
corresponding to the new bit position, 
all registers used. 



LD 


HL, (OFFSET) 


;->configurable data 


LD 


E,(HL) 


jdata byte in reg E 


LD 


A, (CFGD) 


;bit field mask 


LD 


B,A 


; . . in B 


CPL 




; invert it (logical NOT) 



LD 


C,A 


CPL 




AND 


E 


RLCA 




LD 


D,A 


INC 


C 


DEC 


C 


JR 


Z , INFN7X 


AND 


C 



JR 



; .not. mask in C 

; recover mask 

; isolate the bit field 

;left circular rotate 

; save rotated field 

8 bit field? 
. .done if so 
test for overflow 
beyond field 
z=no overflow 



Z,INFN7X 

;a bit has shifted out of the high position 

;of the field. The field is now all Os and 

;the shifted bit belongs in the Isb of the field. 

LD A,C ; synthesize a new field 

RLCA ; with Isb set 

AND B ; remove all other bits 

LD D,A ; save the initialized field 



: LD 


A,(HL) 


;data byte 


AND 


C 


; remove bit field and 


OR 


D 


; replace with rotated field 


LD 


(HL),A 


;new data byte 


LD 


A,D 


;new field in A 


JR 


LDFN7A 


; . . for screen update 
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2. Rotate the resulting byte left one bit position. 

3. Use the inverted Mask to test for overflow outside the bit 
field boundaries. 

4. If overflow has occurred, create a new bit field with Isb 
set. 

5. Replace the bit field in the configuration byte with the 
field from 2 or 4. 

6. Update the field in the configuration block data 

7. Use LD_FN7 to update the screen image, skipping over 
the test for an illogical mask. 

As the code was written, the algorithmic steps were para- 
phrased and expanded in the comment field. Note the coding 
strategy: the byte to be configured is stored in E. The mask is 
stored in B and its inversion is placed in register C. The 
rotated bit field is stored in D, where it can be easily replaced 
in case of overflow (step 5). 

Note the sequence 'INC C, DEC C to test for an 8 bit field. 
C contains the inverse of the mask and will be all zero bits if 
the field is 8 bits wide (the entire byte). This sequence is a 
simple way to set the Z flag from any 8 bit register without 
changing its value. If the value is zero then the RLCA instruc- 
tion has properly rotated the byte and there is no overflow to 
be concerned about. Otherwise, a bit may have been shifted 
out of the msb of the field, leaving the field itself all zeros. 

The first 8 lines of code in LD_FN7 establish HL as a 
pointer to the data being configured, load the isolated 
(masked) bit field into A, and perform an error check on the 
mask byte. IN_FN7 has been designed so that, at the end of 
step 6, HL and A contain the same two values. The entry into 
LD_FN7 skips over these first 8 lines because the mask check 
is not needed; it was done during program initialization by a 
call to LD_FN7. Those 8 lines are executed just once. We'll 
have more to say about them later. 

The algorithm for LD_FN7A...LD_FN7X is: 

1. Shift the bit field right until the isb of the mask is at bit 
position 0. 

2. Get the pointer to the list of strings (S_LIST) 

3. While <bit field lsb> is zero 

Shift bit field right 



Advance pointer to next string 
End While 
4. Copy the string to the screen image (at SADDR) 

Advancing a pointer to the next null terminated string and 
copying a null terminated string from one place to another 
are tasks performed in many places in ZCNFG, so these tasks 
were written as subroutines in a separately linked module, 
CFGSUBS.Z80. It is typical practice to use subroutine calls for 
common tasks; ZCNFG depends on subroutines from rel 
libraries as well. To make use of such subroutines, the 
programmer must become familiar with what is available in 
each library (or linked module) and how to use each 
subroutine. CFGLIB, written for ZCNFG, is accompanied by 
a HLP file which explains how each subroutine is used and 
what it does. VLIB, Z3LIB, SYSLIB, and others are similarly 
documented. Studying such documentation carefully and 
then using library routines saves a lot of coding and 
debugging. 

Did you try solving the problem stated at the beginrung of 
this article? It sounded a little theoretical, didn't it? The obvi- 
ous approach is to rotate the byte 8 times, counting 1 bits, 
followed by a test of the count to see if it is less than 2. That 
approach will work. It requires a loop (typically imple- 
mented with DJNZ), a conditional jump around the code 
which increments the counter, a compare statement, and 
code to initialized the bit counter and the loop counter. Such 
a routine can be written as a subroutine which takes about 17 
bytes of code, including the RET statement. The cost in exe- 
cution time is about 86 T-states. If you got it done in only 
three in-line bytes, congratulations! 

This problem was originally published in Dr. Dobbs 
Journal about 10 years ago, but with an extra qualification 
that made a real challenge of it. The code was to be three bytes 
long! I didn't solve it. 1 had to wait for the next issue for the 
answer. And ZCNFG is the first time I actually had use for it! 
Here's the explanation and a little rationale for being aware 
of such things. They are called 'coding tricks', but really are 
methods of making best use of your CPU architecture and 
instruction set. Lee Hart gives an excellent discussion of 
performance oriented programming in TCJ issues 39 and 40 



LD_FN7 : 
Copy the string in the overlay corresponding 
to the bit set in the field to the screen image. 
This is the entry for MAPPER, during initialization 
The data structure at OFFSET: contains current data, 
exit- (normal) AF = 0,NZ,NC 

(error) program abort with message 
on bad CFGD byte. 

LD A, (CFGD) 
;test for illogical mask with less than 2 bits set 



LD 
DEC 



AND 



B,A 
A 



JP 


Z,BftDOVL 


LD 


A,B 


LD 


HL, (OFFSET) 


AND 


(HL) 



; save the mas)c byte 

; invert low order Os and 

;the first 1 encountered 

; restore ' s from original 

;byte and set Zflag 

; (NZ if I's remain) 

; error if <2 bits in the mask 

; restore original byte in A 



;bit field at (HL) in A 



LDFN7A: 

;This is the entry from IN_FN7. 

; shift bit field right to Isb position for indexing 



; entry- 


A = field from cfg data, 
B = mask for field data 


masked 




HL -> 


cfg data byte 








BIT 


0,B 




;mask & data 

; right justified yet? 




JR 


NZ,LDFN7B 




,-yes, if nz 




RRCA 






;move bit field right 




RRC 


B 




;and also the mask 




JR 


LDFN7A 




;and repeat 


LDPN7B: 










; index 


to the 


proper string 


in S 


_LIST 




LD 


HL, (S_LIST) 




;->fielddata list for screen 




LD 


C,A 




;cfg field in C 


. . INDX 


BIT 


0,C 




,-l3b set? 




JR 


NZ,LDPN7X 




;use current list item if so 




CALL 


SKIP2Z 




; else skip to next list item 




RRC 


C 




; and put next field bit in Isb 




JR 


..INDX 




; . . and repeat 



LDFN7X: 

;copy S-LIST string to screen image 

LD DE, (S_ADDR) 

CALL M0VE2Z ; copy null terminated string 

XOR A ;no error 

RET 
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(July & Sept, 1989). This is highly recommended reading! But 
Mr. Hart does not discuss this 'trick'. 

By now, if you've been reading the listing of LD_FN7, you 

will have found the three bytes. They follow the ';test for ' 

comment line. Consider what happens when a byte is decre- 
mented (subtracting 1 is equivalent but takes an extra byte). 
Assume that the byte in A is 01111000, our first example. 
When this byte is decremented, it becomes 01110111. Note 
what has changed: all the O's at the right have become I's, 
and the rightmost 1 has become a 0. Bits to the left of the 
rightmost 1 are unchanged. If this result is ANDed with the 
original byte, all the changed bits become 0, and the value of 
the byte is determined only by the unchanged bits. If these 
bits were originally 0, then the result will be 0. Figure 2 shows 
three examples, one for a reasonable mask byte, and two for 
illogical mask bytes. These latter two are illogical because the 
mask byte specifies the size of the bit field to process; it 
makes no sense to rotate a bit in a zero length field or in a 
field of length one. Since the final AND adjusts the Z flag, a 
result of NZ implies an acceptable mask and Z an invalid 
mask. An invalid mask can arise from an error in writing the 
CFG file or from a damaged file. 

Error Checking 

The current example illustrates a type of error that would 
normally occur only when developing or changing a CFG 
file: an erroneous value in a case table record. Such an error 
could arise by forgetting to include an item in the record, 
making it too short. Because such mistakes are hard to find, 
the BADOVL error routine takes advantage of the table 
driven nature of the SETOPT routine. BADOVL uses the in- 
formation in MENLST and OFFSET to report the Menu and 
Case table record number in which the error was detected. 
Except for the remote possibility of a damaged file, the nor- 
mal user of ZCNFG will never see this class of errors, but the 
CFG file programmer will be thankful when they don't occur 
and grateful when they do! 



Exit 

Some of the concepts important to structured programing 
have been illustrated with the implementation of a major 
function in ZCNFG. We saw that the environment of a 
program structure comprises Data Structures, register usage, 
subroutines both local and from other modules, and error 
handlers. The environment is more commonly referred to as 
the Interface of the routine with the rest of the program. Data 
flow analysis was introduced and is a basis for the 



figure 2. Typical Mask Byte 


Testing. 




A 

A-1 

A & A-1 


Good Mask 

01111000 
01110111 
01110000 


Bad Maskl 

00001000 
00000111 
00000000 


Bad HaskO 
00000000 

11111111 

00000000 



Algorithm(s) that describe the final goal of the AL code. 
Much of this is familiar to HLL programmers; such struc- 
turing is a major goal of High Level Languages. What is to be 
learned from the simple coding problem? Probably that there 
is usually more than one way to implement the solution to a 
problem, and that other solutions might be more efficient (or 
even more elegant!). Here we also saw a subtle emphasis 
shift in our view of one of the CPU instructions: what was 
viewed as an arithmetic operation is really a specialized logic 
function which can be used to advantage. INC and DAA 
may also be viewed as logical operators and might have 
some clever uses. Can you think of others? 

I hope you have become convinced that you, too, could 
program a function for ZCNFG. Want to try? Take a look at 
Function 6 (parse/ deparse all or part of a filespec). It cries 
out for a re-write! Or make a new function whose purpose is 
to configure a printer control string. At the very least, use the 
techniques of structured programming to make your pro- 
graming efforts more elegant and rewarding. There's nothing 
like clean source code when it comes to the inevitable debug- 
ging or enhancement of your program.© 



Reader, from page 2 

Frankly, I'd feel pretty silly not extending the trial subscription 
offer to "chaps like you. " I was a chap like you — spent twenty-six 
years in the tropics. Ever hear of Truk? Ponape? Palau?—Ed. 



1 became aware of TCJ through the Usenet newsgroup 
comp.kng.forth. The articles that show up there periodically 
mention your magazine. It seems to be of a similar flavour to 
the late lamented Micro Cornucopia and also of early Byte. 

I like this "older style" of magazine. It tells you how to get 
stuff done with what you've got instead of forking out big 
bucks for someone else's solution. 

D.C., Ottawa ONT 

You have the basic idea. Not much money in putting out a rag 
this way, which explains why others aren't doing it. Most of the 
industry has outgrown its roots. — Ed. 



I appeal to Z-programmers to enforce CP/M compatible 
programming. An example: implementing a fbced environ- 
ment array near the beginning of a file and to set the address 
at 109H, so that in a non-Z environment this fake environ- 
ment would be used. 



Second, I thought to bring the use of semigraphics to own- 
ers of poor terminals as well. The way to go would be to use 
a dummy graphics on/ off sequence (or omit it totally) and to 
use "+" and "-" for Graphic Character replacements. This 
would certainly open truly portable graphical programs to 
everybody. It would mean reworking the Z3TCAP.TCP to 
this standard for all terminals, and then leaving it up to 
individual users to soup them up to the real stuff, except for 
those extended TCAPs already known. 

Also I'd like to see a remake of TCMAKE, (which used to 
work nicely in the old days of simple terminals), that would 
create the new standard: TCAPs compatible to VLIB 4D 
menu-driven, so a typical Auto-Install-Z-system-user can do 
this himself! 

H. J., Ismaning Germany 

You will appreciate Jay Sage's topic this issue. — Ed. 



1 have been a journal reader now for about two years or 
more. 1 enjoyed it very much before, but 1 must say that 1 
enjoy it even more, now. Your new ideas, perspectives and 
format are very good and I look forward to each edition. The 

See Reader, page 44 
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The NZCOM lOP 

A General-purpose lOP Loader Module 



By Terry Hazen 



When an lOP REL module is loaded into the NZCOM lOP 
buffer by NZCOM or JetLDR, you have no way to configure 
the lOP module. The only way its configuration can be 
changed is to modify the source code and reassemble and 
relink it. 

This time, we'll look at lOPLDR, a small general-purpose 
lOP loader REL module that does most of the standard work 
that it takes to load, control and remove ari lOP module. It is 
combined with an lOP REL module and some lOP module- 
specific routines to create a stand-alone COM file that will 
load, control and remove the lOP module and allow the lOP 
module to be configured by ZCNFG before loading. 

We'll demonstrate lOPLDR by using it to create the stand- 
alone lOP clock display utility I0PCLK.COM. lOPCLK 
provides the lOP clock-specific routines and messages 
needed by lOPLDR as well as the configuration area for use 
by ZCNFG. It also takes care of automatically finding the 
ZSDOS clock driver address at run time. Keep in mind that 
while lOPCLK is the specific example in this article, lOPLDR 
is a general-purpose module. You may use it to create a 
utility to load an lOP module you already have or a special 
one you've always wanted to write. 

lOPLDR is based on RSXLDR, a similar generalized RSX 
loader 1 wrote for HP14 and is similar to, but less specialized 
than, the lOPLDR.REL module included in HP14. lOPLDR 
also incorporates parts of several other utilities, including 
Hal Bower's SPEEDLDR.Z80. Portions of the code were de- 
rived from Bridger Mitchell's Advanced CP/M column on the 
Plu*Perfect CP/M 2.2 RSX standards in TCJ 34 and the 
word-wide relocator was derived from his column on reloca- 
tion in TCJ '33. 

lOPLDR is a generalized lOP loader module. It performs 
preload checks, environment validation and relocates the lOP 



Terry Hazen has a background in analog electronic and mechanical engineering. 
He is currently a product design consultant, specializing in medical electronic sys- 
tems. He encountered his first computer in the 1960's and got very frustrated 
trying to write small punched-card batch-processed ALCOl programs. He got his 
first Z80 computer in 1982 and has been pursuing Z80 hardware and software 
projects ever since. His company, n/SYSTEMS, produces the MDISK 1 megabyte 
add-on RAM disk for Ampro LB computers. MDISK also provides the Ampro with 
bank-switching capabilities for operating system expansion. Terry enjoys design ing 
and building varied types of hardware and software projects, not all of them com- 
puter-related. His recent software projects include the HP and HPC RPN calcula- 
tors and the REMIND appointment reminder utility as well as upgrades to his 
SCAN text file viewing utility and ZP file/ disk/ memory record patcher. He may be 
reached by voice at (408)354-7188 or by message on Ladera Z-node #2. His address 
is 21460 Bear Creek Road, Los Gatos, CA 95030. 



module to the I OP buffer. It is called by a module-specific 
lOP loader utility that contains all module-specific installa- 
tion routines and messages. The actual lOP module is as- 
sembled and linked to a PRL file and appended to the end of 
the module-specific I OP loader COM file. 

The lOPLDR module (Listing 1) and the loader utility, 
lOPCLK (Listing 2), are closely related, like interlinked fin- 
gers. Their relationship is also somewhat backward from the 
way utilities normally work with the REL modules they call. 
Here, lOPLDR contains all of the main routines and does all 
of the standard work. It's lOPCLK's job to provide all of the 
special routines and information that allow lOPLDR to deal 
with the specific requirements of the lOP clock module. In 
fact, even though the name of the utility is lOPCLK, lOPLDR 
is calling routines in lOPCLK rather than the other way 
around. 

lOPLDR 

If you look at the lOPCLK code, you'll notice that the first 
thing it does when it is run, is jump to lOPLDR, which then 
takes control. lOPLDR starts out by doing all the mundane 
and necessary things a utility usually does. It saves the sys- 
tem stack pointer, sets a local stack, displays the sign-on ban- 
ner and does some system checking to make sure it's operat- 
ing under ZCPR3 with an extended environment. 

If the system passes muster, lOPLDR locates the start of 
the PRL header for the lOP clock module that has been ap- 
pended to I0PCLK.COM. $MEMRY is a word that the linker 
fills in with the address of the next available byte of memory 
after the last module used by lOPCLK has been loaded and 
resolved. Since lOPCLK will be assembled and linked with- 
out the lOP clock module PRL file, which will be appended 
later, the $MEMRY pointer will help us locate the beginning 
of the appended CLKIOP.PRL file. 
We'll file the information away for fu- 
ture use and then locate and save the 
lOP module information we'll need for 
relocation later on. 

Now that we know where to find 
the lOP module, we can get and save a 
pointer to its name so that we can use 
it in the help message. Only then do 
we check to see if help has been re- 
quested. When a help message is re- 
quested, you'll notice that the help 
routine, MHELP, displays several 
module-specific strings that are located 
in the calling utility, lOPCLK. lOPCLK 
contains MDESC, the description of the 
lOP module. The description for 
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Listing 1 
Module: 
Author: 
Date: 
Version: 



lOPLDR 
Terry Hazen 
06/07/91 
1.1 



Note: lOPLDR conforms to Joe Wright's Standard Z -System 
I/O Package structure, version 4.0, May 4, 1989. lOPLDR is 
based on RSXLDR, which incorporates parts of several 
utilities, including Hal Bower's SPEEDLDR.Z80 and parts of 
the loader portion of my own HPRSX.Z80. Portions of the code 
were derived from Bridger Mitchell's Advanced CP/M column in 
TCJ#34, p30 on the Plu •Perfect CP/M 2.2 RSX standards and 
the word-wide relocator was derived fron his column in 
TCJ#33, pl4 on relocation. 



ASCII equates 



bell equ 


07 


If equ 


10 


cr equ 


13 


; CP/M equates 




fcb equ 


005ch 


cmdbuf equ 


0080h 


r 

; lOP offsets 




f 

oiopid equ 


35h 


; We need to use thest 
1 



; Default File Control Block 
; Command buffer 



; Offset to lOP name 



.request syslib 

ext cout , eprint , epstr , phl4hc , ccai^ib , $inemry 



Let the target lOP loader utility use our routines: 



lOP 



public iopldr 
public uname 



public mname 



public iop 
public nziop 



Main IOP loader entry point 
Displays leading spaces, 
the name of the IOP loader 
utility and any trailing 
message 
Displays the name of the 

; module and any trailing 

; message 

; Address pointers: 

; local IOP module 

: NZIOP buffer 



Module-specific msgs located in target IOP loader utility: 



ext 

ext 



' name 
mdesc 



; Loader utility name 
; Module description for 
; help screen. 

Module-specific routines located in target IOP loader 
utility: 



ext mcml 
ext mldmsg 



Displays any special 

command line help 
Displays any special load 

message after load address 

is displayed 



MPARS - Parse command line. Any IOP special command line 
parsing, system checks and coomcmd routines can be done 
with this routine. 
Entry; HL=FCB+1 

Exit: CARRY set if error - quit without doing installation 
Z set if system checks OK, but no parsed commands 

found, check for bad command before installing IOP 
NZ set if system checks OK and parsed command found, 
IOP can be installed without further checks 
ext mpars 



; MCFG - Module-specific IOP configuration routine in local 
; memory. Run after the IOP has been relocated and before the 
; internal IOP install routine is run. Does all module- 
; specific IOP configuration. 

; Entry: HL=IX=address of loaded IOP 
; Exit: Z set if error 
; Uses: IX, lY must be preserved 
ext mcfg 



MINST - Module-specific IOP install routine in local memory. 
Run after the IOP is relocated and the internal IOP install 
routine has been run. Does all module-specific installation. 
Entry: HL=IX=addres3 of loaded IOP 
Exit: Z set if error 
ext mlnat 



Ccanmand line help screen 



mhelp : call 
db 
db 
call 

db 

Id 
call 
7 

call 
db 
db 
db 

call 

db 

call 

db 

db 

call 

db 

db 

call 



eprint 

'Installs and removes the IOP module for the' 
cr,lf,' ',0 

mname ; Display module name 

and description 
No trailing message 



hi, mdesc 
epstr 

eprint 

'. ',cr,lf 

'Syntax: ' 
cr,lf ,0 

uname 

' Install 
mname 

' IOP module ' 
cr,lf,0 



uname 

' R Remove IOP module' 

cr,lf,0 



Display module description 



mcml 
mldmsg 



; Display any special commands , 
; loaded IOP ccinmands and 



quit 

Main module entry 



iopldr : Id 
Id 
Id 
push 



{ stack ) , sp 
sp, stack 
hi, exit 
hi 



; Put exit address on stack 



Display program name, then move down one line and in 4 
spaces, ready for the display of ccmmon messages. 



; Point to name string 
; Display it 

,0 

; Get environment address 
; First character of ID string 

; Not Z-system, so quit 

; Get Z3ENV Type in A 
; Rotate bit 7 to carry 
; Quit if not extended ENV 

; Get EFCB address in HL 



; Check for existence 
; No 



banner: 


Id 


hi, name 




call 


epstr 




call 


eprint 




db 


or, If,' 


/ 


Id 


ix,(109h) 




Id 


a, (ix+3) 




cp 


'Z' 




jp 


nz , notez 




Id 

rla 


a,(ix+8) 




jp 


nc, notez 




Id 


l,(ix+24h) 




Id 


h,(ix+25h) 




Id 


a,h 




or 


1 




jr 


z,getprl 
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lOPCLK is 'Video Clock lOP'. MHELP can also display any 
special loader utility commands and loaded lOP commands 
located at MCML and MLDMSG respectively. 

At MCML (in lOPCLK), we find a description of the 'D' 
option, which controls the lOP clock's display format. In this 
case, lOPCLK doesn't need a message at MLDMSG, so it 
simply returns. In more complex lOPs, the message at 
MLDMSG can display commands that can be executed by the 
loaded lOP. The Alpha Systems RECORDer lOP, for ex- 
ample, has commands that allow you to turn the recording 
functions on or off and allow you to specify the names of the 
files to which the console and list output are being written. 

If no help has been requested, we can now get the address 
and size of the NZCOM lOP buffer from the environment 
and make sure it exists and that it is big enough for our lOP 
module. 

Removing the lOP Module 

Now we can parse the command line and see if we are 
being asked to load or remove our lOP clock module. If 
we're removing it, we only have to make sure that the cur- 
rent lOP module has the same name as ours. If it does, we 
deselect it by calling the SELECT routine in the lOP with 
B=OFFh. We can then tell the user that the module has been 
removed and quit. Even though it's probably not absolutely 
necessary, we do the name test to make sure that each lOP 
module is removed by its own utility just in case there's 
something special about it or about its removal process. 

Loading the lOP Module 

If we're not being asked to remove the lOP module, we 
call MPARS in lOPCLK to parse the command line for any 
special commands and do any special system checks we 
might need. In our case, we want to check to make sure we 
have a working ZSDOS/ZDDOS system clock. We first use 
the extended DOS ID call 48 to make sure we are operating 
under ZSDOS or ZDDOS. If we are, we make sure we have a 
clock by using the DOS 98 call to do a trial clock read. 

If the user has requested that we install the lOP, we copy 
the 10? module to the lOP buffer and using the PRL bitmap, 
relocate it in place by adjusting the module addresses to re- 
flect the move (see Bridger Mitchell's Advanced CP/M column 
in TCJ 33 for more information on relocation). 

Now that the module is in place, we call MCFG in 
lOPCLK to do any module-specific configuration that may 
be required. In our case, we need to find and save the loca- 
tion of the ZSDOS clock driver and we need to move the 
configuration buffer from the start of I0PCLK.COM to the 
loaded lOP clock module. 

Like all good lOP loaders must, we then call the initializa- 
tion routine in the lOP module. Before we can quit, we call 
MINST in lOPCLK to do any module-specific initialization. 
In our case, none is required. We then display the address of 
the lOP buffer and finally, call MLDMSG in lOPCLK to dis- 
play any special load message our module might require. 
lOPCLK doesn't require anything special, so we're done. Our 
lOP is loaded, configured and running until we remove or 
replace it. 

Configuring the lOP Module 

If you chose to load CLKIOP.REL with NZCOM or 
jETLDR, you had to add all the configuration information to 
the CLKIOP source code before you assembled it to a REL 



file. This means, of course, that you'll have to change and 
reassemble and relink the source code each time you want to 
change the configuration. To make configuration easier and 
more flexible, there is a configuration buffer at the beginning 
of I0PCLK.COM. This buffer can be configured with 
ZCNFG and is copied to the lOP module configuration 
buffer after the module is loaded into the lOP buffer. 

You can configure the lOP clock module to sound an 
alarm every hour, to display the time as hh:mm and update 
the display every minute or to display the time as hh:mm;ss 
and update the display every second, and to display the time 
in 12 or 24 hour format. This is also where you must specify 
the special terminal control sequence that is required to place 
the clock display in the terminal's host computer message 
field. 

Producing I0PCLK.COM 

We can now assemble and link IOPCLK.Z80 with 
lOPLDR.REL and SYSLIB to make 10PCLK.COM. Note that 
lOPLDR.REL requests the required SYSLIB routines, which 
are public: 

ZMAC IOPCLK;ZML lOPCLK 

We need to have the CLKIOP module available as a PRL 
file, which contains the bitmap that we need in order to relo- 
cate it (see Al Hawley's Getting Started in Assembly Language 
column, TCJ 50). First we assemble CLKIOP.Z80 to a REL 
file and then link it to a PRL file: 

ZMAC CLKIOP ;ZML CLKIOP /P 

We can then use CONCAT with the binary-append op- 
tions to append CLKIOP.PRL to the end of I0PCLK.COM to 
produce our final stand-alone lOP clock utility: 

CONCAT IOPCLK.C0M=CLKI0P.PRL /OA 

You can now run lOPCLK to load the lOP clock module. 
You can also use it to remove the lOP module and to change 
the display from 12 to 24 hour time. 

You can find the full source and documentation for 
lOPLDR in lOPLDRll.LBR on your favorite Z-Node. I hope 
lOPCLK and lOPLDR will give someone an idea that will 
soon lead to a new and innovative lOP module showing up 
in these pages!# 



/^ 



TCJ On-Line 

Readers and authors are invited to join in dis- 
cussions with their peers in any of three on-line 
forums. 

• GEnie Forth Interest Group (page 710) 

• GEnie CP/M Interest Group (page 685) 

• Socrates Z-Node 32 

For access to GEnie, set your modem to half 
duplex, and call 1-800-638-8369. Upon connec- 
tion, enter HHH. At the U#= prompt, enter 
XTX99486,GENIE and press RETURN. Have a 
credit card or your checking account number 
handy. 

Or call Socrates Z-Node, at (908) 754-9067. 
PC Pursuit users, use the NJNBR outdiaL 



^ 
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inc 


hi 


; Point to first name byte ; 












Id 


de.naine 


; Move name to our buffer i 


emove: 


Id 


hi, (nziop) ; 


Get lOP buffer address 




Id 


be, 8 






Id 


de , oiopid ; 


Offset to lOP name 


1 


Idir 








add 
Id 


hl,de ; 
de, (iopid) 


HL=IOP name 
DE=our name 


getprl: 


Id 


hi, ($iiiemry) 


; Get end of code 




Id 


b,8 






Id 


a,l 


; Find start of PRL header 




call 


compb ; 


Same? 




or 


a 






jr 


nz , notsam ; 


No , don ' t remove 




jr 


z,Btart2 














cp 


80h 






Id 


b,Offh ; 


Deselect lOP 




jr 


z,start2 






call 


select 






add 


80h 






jr 


2 , nosel 






jr 


nc, startl 


i 












inc 


h 






call 


mname 




; 










db 


' lOP module removed' ,cr, If ,0 | 


startl: 


and 
Id 


80h 
l,a 


i 
r 


losel : 


ret 
call 


eprint 




starta: 


push 


hi 


; HL=PRL header 




db 


'lOP select funct 


ion not supported ' , or , 1 f , 




inc 


hi 


; Point to PRL size 




ret 








Id 


e,(hl) 














inc 


hi 


r 


lotsam: 


call 


eprint 






Id 


d,(hl) 






db 


'Remove current lOP module ',0 [ 


/ 


Id 


(size) ,de 


; Save PRL size , 




Id 


de , rmsg 






pop 


hi 


; HL=PRL header 




push 


de 






inc 


h 


; HL=IOP 




call 


pn$0 


Display name 




push 


hi 














pop 


iy 


; HL=IY=local lOP module i 


Tnsg: 


db 


' with its own utility. ' | 




Id 


(iop),hl 






db 


cr,lf,0 






Id 


de , oiopid 






ret 








add 

Id 


hl,de 
(iopid), hi 


; HIj=address of lOP name 
; Save it 




















/ 








Call 


lOP module SELECT routine 






Id 


hl,fcbl-2 


; Check for help request 












Id 


a, (hi) 


I 


ielect : 


Id 


hi, (nziop) ; 


Get lOP buffer address 




cp 


■/' 


; Help request? 




Id 


de,3 ; 


Offset to lOP SRT.RCT 




JP 


z,mhelp 


; Display help screen 




add 
JP 


hl,de 

(hi) ; 


Call lOP SELECT 


; Get the lOP 
getiop: Id 


buffer address 
l,(ix+15) 












; lOP buffer address in the 


Copy 


the lOP 


module to the lOP 


buffer 








; environment 












Id 


h, (ix+16) 




Lnstall 


:ld 


hl,(iop) ; 


HL=local lOP module 


. 


Id 


(nziop) ,hl 


; Save lOP buffer address 




Id 
push 


de, (nziop) ; 
de ; 


DE=loaded TOP buffer 
Save 4 copies 




Id 


a,(ix+17) 


; Get IOPS size in records 




push 


de 






or 


a 


; Check for zero 




push 


de 




. 


JP 


z , noiop 


; Quit, no lOP 




push 
Id 


de 

be, (size) ; 


Length of lOP-bitmap 




rra 




; *80h 




Idir 




Move the module 




Id 


h,a 


; HL=size 




call 


reloc , 


Relocate the code 




Id 


1,0 














Id 


( iops ) , hi 


; Save it 




pop 


hi 


Restore loaded TOP pointer 




or 


a 


; Clear CARRY 




pop 


ix 


HL=IX 




Id 


de, (size) 


; Size of lOP 




call 


mcfg 


Do module-specific 




sbc 


hl,de 










configuration 




DP 


c , smiop 


; lOP too small for this 




ret 


z 


Configuration error 


module 
















; 










pop 


hi 


HL=loaded lOP buffer 




Id 


hl.fobfl 


; Parse command line 




Id 


de,9 


Offset to lOPINIT 




Id 


be, 8 


; Scan name field 




add 


hl,de 






Id 


a,'R' 


; Check for 'R'emove 




call 


jphl 


Call the lOP install 




cpir 






routine 










jr 


z , remove 


; Yes , remove I OP 










/ 










pop 


hi 


Restore loaded lOP pointer 




Id 


hl,fcbfl 


; Parse command line 




call 


minst 


Do module-specific install 




call 


mpars 


; Do any special parsing and 








routine 








; routines 




ret 


z 


Installation error 




ret 


c 


; Error, so quit 










? 


JP 


nz, install 


; Ok to install lOP 




call 
db 


mname 

' lOP module insi 


:alled at ',0 




Id 


hl,fcb+l 


; Point to command tail 




Id 


hi, (nziop) 


Get lOP load address 




Id 


a, (hi) 






call 


at 


Display load address 




cp 


' ' 


; Any ccanmand tail? 




JP 


mldmsg 


Display module-specific 




JP 


z, install 


; No, OK to install lOP 








load message 




JP 


mhelp 


; Yes, must be bad command 


















; Main 


exit point 








; Remove lOP 


module 




sxit: 


Id 


sp, (stack) 
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Error returns: 

No extended Z-syatem present 

notez: call eprint 

db 'Requires ZCPR3 system with ' 

db ' extended environment 1 ' 

db cr,lf,bell,0 

ret ; And quit 

No lOP present 

noiop: call eprint 

db 'No lOP bufferl ' ,cr,lf ,bell,0 
ret ; And quit 

lOP buffer too small 

smiop: call eprint 

db 'lOP buffer is too smalll ' ,cr,lf ,bell,0 
ret ; And quit 



Bridger Mitchell's word-wide PRL relocator (TCJ#33 pl4). 
Patches lOP addresses after lOP has been loaded to high 
memory. Bitmap remains in local memory. 

; Save interrupt vector in 



; Disable interrupts while we 
; use stack 

; IX=zero 

; Save stack pointer in IX 

; Relocation address 



reloc ; 


Id 


a,i 


AF' 








ex 


af,af ' 




di 




/ 


Id 


ix,0 




add 


ix,sp 


1 


Id 


hi, (nziop) 




push 


hi 




exx 






pop 


de 


cede 


dec 


d 



Id 


sp,hl 


dec 


sp 


Id 


hl,(iop) 


Id 


be, (size) 


add 


hi, be 


Id 


e,l 



rloop: 


Id 


a,b 




or 


c 




jr 


z , rdone 


/ 


dec 


be 




rrc 


e 




jr 


nc, rsame 


' 


Id 


d,(hl) 




inc 


hi 


rsame: 


rlc 


d 




jr 


nc , noof 


' 


exx 






pop 


hi 



; Set DE'=base address of 

; COTipensate for lOOh org in 
; PRL file 



SP=start of code - 1 byte, 
since we need to mark high 
byte 

Start of local lOP module 

Length of relocated code 

HL=bitmap 

Init the rotation byte, 

which will set CARRY every 

8 bytes 

; Check byte count 

; Done 

; Reduce byte count 

; Set CARRY every 8 bits 

; Not set 

; D=next byte from bitmap 
; Advance bitmap pointer 

; Shift bitmap byte into CARRY 
; No relocation needed 



; Get word to relocate from 
; stack 





add 


hl,de 


address 








push 


hi 




exx 




noof: 


inc 


ap 




jr 


rloop 


rdone : 


Id 


sp,ix 




ex 


af,af 




ret 


po 




ei 






ret 





; Relocate by DE'=load 
; Put it back 



; Point to next byte of code 
; And deal with it 

; Restore the stack 

; Restore interrupt vector 

; Interrupt was DI, so skip 

; enable 

; Otherwise enable interrupts 



Display the lOP module name andthe trailing inline message. 



mname: 


push 


hi 


; Save message pointer 




Id 


hi, (iopid) 


; Point to name 




jr 


pn?0 


; Display it 



Display 3 leading spaces, the filename and the trailing 
inline message. 



; Save message pointer 
; 3 leading spaces 



; Display the spaces 

; Point to our name buffer 

; Get byte 

; Quit at 

; Point to next character 
; Filter high bit 

,- Ouit at first space 



; Restore message pointer 
; Display trailing message 



unatrte: 


push 


hi 




Id 


b,3 




Id 


a, ' ' 


splp: 


call 


cout 




djnz 


splp 


' 


Id 


hi, name 


pn$0: 


Id 


b,8 


pn$loop 


:ld 


a, (hi) 




or 


a 




jr 


z , pn$dun 


' 


inc 


hi 




and 


07fh 




cp 


' ' 




jr 


z , pn$dun 




call 


cout 




djnz 


pn$loop 


pn$dun: 


pop 


hi 




JP 


eprint 



Display hex load address, start new line. 



It: 


call 


phl4hc 




call 


eprint 




db 


'H',cr,lf,0 




ret 




; Call 


(HL) 




jphl: 


JP 


(hi) 



Initialized data area 



iop: 


ds 


2 


size: 


ds 


2 


nziop: 


ds 


2 


iops: 


ds 


2 


iopid : 


da 


2 


' 


ds 


48 


stack: 


ds 
end 


2 



Start of local IOP module 
Size of PRL 
Start of NZIOP buffer 
Size of IOP buffer 
Address of local IOP name 

; Local stack 

; System stack pointer 



; End of IOPLDR.Z80 



'There are a lot of lies goirng around.... and half of thenn are true." —Winston Churchill 
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Listing 2 
Module: 
Author: 
Date: 
Version; 



lOPCLK 
Terry Haaen 
06/07/91 
1.0 



Equates 



off 


equ 





on 


equ 


Offh 


bdos 


equ 


5 


bell 


equ 


7 


If 


equ 


10 


cr 


equ 


13 


esc 


equ 


27 



Program version for use in banner and CFG filename 

rovers equ 10 

Entry points for module-specific addresses and routines 
required by the lOPLDR module: 

public name,mdesc,mcml,mldmsg,mpars,mcfg,minst 

From lOPLDR we need: 

. request iopldr 

ext iopldr, iop,nziop,unaine 

ext cout , eprint , phl4hc , $memry 



IOPLDR does all the work 

ZCPR3 Utility 

Type 1 

Z3ENV address provided 

by ZCPR33+ 
ZCPR34 pad bytes 



enter: jp 


iopldr 


db 


'Z3EHV' 


db 


1 


z3eadr: dw 






dw 



db 
db 



db 



enter 



'lOPCLK' ; Default CFG filename 
mvers/lO+'O' ,mvers mod lO+'O" 

; 8 characters total 
; Termination 



lOP Configuration area - copied to lOP module at load time 



ON to beep every hour 
ON to include seconds in 

clock display 
ON for 12hr time, 
OFF for 24hr time 
ZSDOS clock driver address 



Prefix to put clock display in terminal message line. The 
prefix and termination character are ccmpletely terminal- 
dependant. This example is for the HySE75: 



config: 






beep: 


db 


on 


seconds 


:db 


on 


time: 


db 


on 


zsclk: 


dw 






term: db 
ds 
db 

termend:dib 

} 

spaces: db 

cfglen equ 



esc,' [>+\' 

3 



'\' 

22 

S-config 



Message prefix 
8 bytes total 
Termination 



; Message termination character 

; Spaces to start of clock 
; display 



lOPCLK-specific routines called by IOPLDR: 



NAME is the zero-terminated loader name and version number 
for use in the banner. 

name : db ' lOPCLK vers ' 

db mvers/lO+'C , ' . ' ,mvers mod lO+'O' 
db ; Termination 



MDESC is a zero-terminated description of the module 
function that is displayed after the module name in the 
command line help screen. 



mdesc: db 



Video Clock lOP ' , 



MCML is displayed after the command line help screen to to 
allow the display of extended command line cconmands. 



mcml : call 
db 
db 

db 
ret 



uname 

' D Toggle time display between 

'(hh:mm) and (hh:mm:ss)' 

cr,lf,0 



MLDMSG is displayed after lOP load/exists messages to allow 
the display of lOP commands. 



mldmsg: ret 



; No message required here 



HPARS does any required special command line parsing, system 
checks and execution of commands other than install and 
remove. 

Entry: HL=FCB+1 

Exit: CARRY SET for error requiring exit without installing 
lOP Z set if system checks ok but no command found. Look 
for badcmd. NZ set if system checks ok and command found. 
Install lOP. 



ntpars : 


push 


hi 


; Save pointer 




Id 


c,48 


; Extended DOS check 




call 


bdos 






Id 


a,h 






cp 


'S' 


; Must be ZSDOS 




jr 


z, clkchk 






cp 


■D' 


; Or ZDDOS 




jr 


z, clkchk 




1 


call 


eprint 






db 


'ZSDOS/ZDDOS 


requiredl ' ,cr , If ,bell,0 




jr 


erret 




; Check 


for good clock 




clkchk: 


Id 


de , clock 


; Check for clock 




Id 


c,98 


; BDOS get time 




call 


bdos 






inc 


a 






jr 


nz,pars 


; Clock present 




call 


eprint 






db 


'Can' 't read 


clock 1 ' 




db 


cr,lf,bell,0 




erret; 


pop 


hi 


; Discard pointer 




scf 




; Set fatal error 




ret 






; Parse 


ccsnmanc 


line 




pars: 


pop 


hi 


; Restore pointer 




Id 


a,'D' 


; Include seconds in display? 




Id 


be, 8 


; Scan name field 




cpir 








jr 


z,tsec 


; Found 


} 


xor 


a 


; Set Z-check for bad command 




ret 






tsec: 


Id 
cpl 


a , ( seconds ) 


; Otherwise toggle 
; display flag 




Id 


( seconds ) , a 






jr 


good 


; Set good return 
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MCFG - does all required special configuration of the lOP 
module after it has been relocated into high 
memory and before internal lOP initialization is 
in. 

Entry: HL,IX=address of lOP buffer, IY=address of local TOP 

Exits Z set if installation error 
NZ set if ok 
IX, lY must be preserved. 



Uses: 



mcfg: 



driver 



exx 

Id 

Id 



hl,(109h) 
de,42h 



add hl,de 

call Ihlhl 

Id de,16h 

add hl,de 

call Ihlhl 



address 



Id 

exx 

Id 

add 

ex 

Id 
Id 
Idir 



(zsclk) ,hl 



de,S2h 

hl,de 

de,hl 

hl,config 
be, cf glen 



; Save lOP addr 

; Get address of environment 

; Offset to ZSDOS clock 

; address 

; Get ZSDOS address 

; Offset to clock address 

HL=address of ZSDOS clock 

routine 
Save it locally 

; Restore lOP address 

; Offset to lOP config area 

; DE=loaded 10? config 

; HL=local config area 

; BC=length of config area 



good: 



or 
ret 



; Set good ( NZ ) return 



MINST - does all required special installation of the lOP 

module after it has been relocated into high memory 
and after internal lOP initialization is run. 

Entry: HL, IX=address of lOP buffer, iy=address of local lOP 

Exit: Z set if installation error 
NZ set if ok 



minst! ret 



; Nothing special required 



Load HL with the two bytes it is pointing to 

Ihlhl: Id a, (hi) ; Low order to A 

inc hi 

Id h,(hl) ; High order to H 

Id l,a ; Low order to L 
ret 



Data area 

clock: ds 6 
end 

; End of IOPCLK.Z80 



Initial clock read buffer 



Computer Comer, from page 48 

picture, text, drawing, and fancy graphics. It sure makes 
me miss using a Macintosh. Icons in and of themselves are 
not the answer to easy use. In Mac machines, especially with 
the release of version 7, the look and feel is so uniform, that 
once a operation or technique is learned, you can use it in all 
programs. 

Contrast this to PC based windows programs and you can 
easily see why the Macintosh is still best. When using a PC, I 
have stopped using the mouse as it is too much work. Most 
of the programs I have all use the mouse differently — no 
standardization. Windows 3 added a more constant look and 
feel, but at present it is still each programming shop to their 
own way of doing things. I feel another 5 years from now 
and maybe the PC world will reach the same level of user 
friendliness that has been available on Macs for more than 5 
years. 

For Mac users or want-to-be-users you do not need to 
spend lots of money. No I am not talking about price drops 
but about other systems. A friend of mine just bought an 
Amiga with a MAC adapter card. He has been able to run 
almost everything available with better graphics and also 
have regular Amiga programs as well. I plan on doing the 
same here soon with my Atari ST. I think I can turn my 1 
Meg machine into a Mac clone for about $300. Now I am not 
positive about prices right now, but I think you could buy a 
new Atari ST for say $1000 (color monitor). The Mac adapter 
at $300 means an Atari/Macintosh for $1300 total. Now this 
is not getting you a classic model, but something closer to 
their Us. For people who want to step up to 68K machines 
and real user friendly software it sure beats the "real thing". 

Up Last 

A last topic is industrial controllers. I was planning on 
reporting on a new controller running Forth, but I haven't 



received the information yet. The person is promising a 
demo model so I feel strongly I should wait and give a more 
complete accounting of the product later. 

What I can report on is the flood of new products and 
interest in this area. I have commented before how it seems 
to be the last area for home grown production. Well it seems 
that a lot of people are taking me at my words. I am sure the 
number of small units available has never been greater. It is 
possible to get everything from 8031 to the newest chip on 
the market in something that fits in your hand. 

If you are going this way a few words of advice. First off 
do your homework. Find someone who needs the product 
and work with them to get it going. This will help you shake 
out all those little "oops" that can slip by so easily. Think 
about your user and just what they need. Don't forget what 
level of knowledge your user may have. Make it a point of 
building and testing everything you say the system can do. 
Be able to prove beyond a shadow of doubt that it will work 
as advertised. Lastly don't do it if you really don't have the 
experience and knowledge needed. 

I receive several industrial trade magazines and have seen 
lately talks about the dangers of poorly designed and tested 
industrial controllers. The project I worked on years ago was 
held up and changed several times due to concerns about 
product liability. When designing the system knowing what 
will happen if this or that fails may be the difference between 
someone saving their life or losing it. These are not items to 
be treated lightly or haphazardly. 

Caution To the Winds 

At this point I feel like throwing caution to the winds and 
saying how next time I will have information for you that 
you will wonder how you ever lived without it. But then 1 
also got abridge to sell as well... .have fun!!!!# 
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Z-Best Software 

Spotlight on Gene Pizzetta 



By Bill Tishey 



What a great time this is for anyone involved with Z- 
System! The "team" of Z developers continues to fill the Z- 
Nodes with new tools and refinements to existing utilities. 
As you can see, the list of new and revised programs is even 



Listing 1 
New Releases: 

Name 



Vers S ZSUS Siz Rec CRC Library/Size Issued Author 



CFGZ.COM 1.00 6 47 F829 CFGZIO 
SYS User-modified version of AMPRO CONFIG 2. 
HLP=N operation under both CP/M and NZCOM. 
CFG=Y 



5 05/03/91 Terry Hazen 
6 utility to allow correct 



MS-DOS self-extracting (.EXE) ZIPfiles. I feel that this 
column will serve its readers best if there are such questions 
to guide it. Let me hear from you! 



Spotlight on Gene Pizzetta 

Gene provides us four new tools 
and updates to three others. As you 
read the following paragraphs, one 
thing should be obvious — Gene's con- 
tinuing work with program support 
for ZSDOS and datestamping in gen- 
eral. 



CMAZE.COM 
SYS 
HLP=N 
CFG=N 



1.80 







28 220 D2AD CMAZE18 39 09/16/91 Lee Bradley 



MBASIC/BASCOM game which uses Z-System TCAP data. Creates a maze of 
walls and asks you to position a ball in the maze. Data entry is 
best done with ZEX scripts. Uses Z3BAS library of routines. 



CPD.COM 1.00 V211 4 29 83D1 CPDIO 21 08/10/91 Gene Pizzetta 

DIR Compares two directories and indicates which files exist in both and 

HLP=Y which exist only in the first. Allows setting of archive bit on 

CFG=Y those files which exist in both directories. 

FILT.COM 0.80 4 30 9588 FILT8 23 09/13/91 Gens Pizzetta 
HP ZCPR3 rework of Irv Hoff's FILT7 tool which sets or expands tabs and 
HLP=N removes several types of unwanted characters in ASCII text, WordStar 
CFG=Y documents or assembler source code files. 

JUST.COM 1.20 4 31 548B JUST12 40 09/13/91 Gene Pizzetta 
WP ZCPR3 rework of Irv Hoff's tool to justify ASCII and WordStar text 
HLP=N files. Full command-line operation, DU support, error-flag setting, 
CFG=Y quiet mode, and transfers create datestamps under ZSDOS. 



longer than that of last issue! This, however, makes my job as 

this columnist even tougher. Due to the limited space here, 

it's impossible to cover everything in detail. What 1 would 

like to do each issue is provide some encapsulated reports on 

what is new and improved. 

Sometimes, as in this issue, 1 may focus 

on the contributions of a particular 

developer. In addition, however, 1 

would like to highlight some programs 

of your choosing. Drop me a line 

(either directly or through the editor) 

with any programs which you'd like to 

see discussed. Maybe you want to 

know more about LSH, Rob Friefeld's 

command-line editing shell. Maybe 

you'd like to see some applications for 

Terry Hazen's ZFIND utility. Maybe 

you're looking for a good file-compare 

utility, or something that will unZIP 



CPDvs1.0{ZSUSVol2#11) 

Gene's ComPare-Directory utility, 
CPD, was an idea derived from CDIR 
vs 2.0 (by Rob Wilcox and Richard 
Brewster) and the result of some 
prompting from Howard Schwartz. 
See Figure 1 for CPD's syntax. 

CPD compares two directories and 
indicates which files exist in both 
directories and which exist only in the 
first directory. If no option is given, all 
matching non-system files in the first 
directory are displayed with files 
marked which also exist in the second 
directory. The duplicated files are 
marked in standout video (if supported 
by one's TCAP) and by an asterisk 
following the filename. The asterisk 

has the added function of allowing visible markings in 

printer output. 

CPD's options allow 1) display of only those files which 

exist in both directories, 2) display of files in the first direc- 



Bill Tishey has been a ZCPR user since 1985, when he found the right combina- 
tion of ZCPR2 and Microsoft's Softcard CP/M for his three-year-old Apple 11+ . 
After graduating to ZCPR30 and PCPl's Applicard CP/M, he did a "manual in- 
stall" of ZCPR3.3 (with help from a lot of friends!), and in late 1988 switched to 
NZCOM and ZSDOS, all on the same vintage Apple 11+. Bill is the author of the 
Z3HELP system, a monthly-updated system of help files for Z-System programs, as 
well as comprehensive listings of available Z-System software. Bill is the editor of 
the Z-System Software Update Service and has compiled such offerings as the 
Z3C0M package and the Z-System Programmer's Toolkit. Bill is a language analyst 
for the federal government and frequents the Foreign Language Forum (FLEFO) on 
CompuServe. He can be reached there (76320,22), on Genie (WATISHE), on fay 
Sage's Z-Node #3 (617-965-7259) and by regular mail at 8335 Dubbs Drive, Sev- 
ern, MD 21144. 
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LOCNDOPT.HEX 1.00 13 8FB5 LOCNDOPT 3 08/01/91 Bruce Morgen 
PR0G4 Patch to LOCNDO.IOM vs 1.2 which adds 1) Z3 extended ENV drive vector 
HLP=N support, 2) "//" help query and 3) proper trap if no valid ENV. 
CFG=N 

MKZ3BASE.COM 1.00 2 9 241E MKZ3BASE 5 77/77/91 H. zur Nedden 
PROG Builds a Z3BASE.LIB by reading the current values for the equates 
HLP=N from the environment descriptor. 
CFG=N 

SSORTPAT.Z80 1.00 2 9 AD42 SSORTPAT 2 08/23/91 Bruce Morgen 
PR0G4 Patch for MicroPro SuperSort vl.60 (S0RT.COM) to allow multiple 
KiP-N SuperSort ccoimanda under ZCPR33+ (including BGii 1.3x, NZCOM, Z3PLUS) 
CPG=N from the system prompt or in Z-System aliases and other scripts. 

TYPELZH.COM 2.00 CO 7 54 191C TLZH20 60 07/27/91 Roger Warren 
LBR Types LZH-eneoded, Crunched, and Squeezed files. Based on TYPELZ . 
HIiP=N Vs 1.0 (8/15/89) by Roger Warren. 
CFG=N 



TYPELZHR.COM 2.00 CO 
LBR See TYPELZH.COM. 
HLP=N 
CFG=N 



7 54 B980 TLZH20 60 07/27/91 Roger Warren 
For R/CPMs with wheel at 03EH. 



WINDWLIB.REL 1.00 6 47 A8D2 WINDOWIO 18 04/29/91 W. Schmitten 
PR0G3 Routines which allow use of up to 15 windows on (any) CP/M computer. 
HLP=N 
CFG=N 

XRUN-EHG.COM 2.50 4 25 45BC XRUN25 38 02/28/91 Olaf Krumnow 
SYS An ECP for ZCPR33. Looks for files along the search path and 
HLP=N constructs a command line depending on the extension of the file 
CFG=N found. Supports shell variables. 

ZBIB.COM O.50 8 64 529C ZBIB05 23 09/15/91 Joe Mortensen 
7DBASE Bibliographic database manager based on ZDB. 
HLP=Y 
CFG=Y 



4 27 F6B4 ZTIME13 
Z3PLUS version. 



25 09/11/91 Gene Pizzetta 



ZTIME+.COM 1.30 
DATE See ZTIME.COM. 
HLP=N 
CFG=y 



ZTIME.COM 1.30 4 27 7E7B ZTIME13 25 09/11/91 Gene Pizzetta 
DATE A hardware independent cloclc utility for setting or displaying the 
HLP=N date and tine under ZSDOS or Z3PLUS. Options include the ability to 
CFG=Y measure elapsed time. ZSDOS version. 



Listing 2 
Revised Programs: 



Name 



Vers S ZSUS Siz Rec CRC Library/Size Issued Author 



CFGLIB.REL 1.00 4 V212 2 10 E955 ZCNFG19 109 08/21/91 Al Hawley 
PR0G3 Library of routines used to link .CFG configuration files used by 
HLP=Y ZCNFG.COM. 
CFG=N 

DATSTP-P.30M 1.70 3 5 39 33C5 DATSTP17 64 08/30/91 Gene Pizzetta 
DATE See DATSTP-U.COM. For Z3PLUS only. Type 3 at SOOOh. 
HLP=Y 
CFG=Y 

DATSTP-P.40M 1.70 4 6 46 3A31 DATSTP17 64 08/30/91 Gene Pizzetta 
DATE See DATSTP-U.COM. For Z3PLUS only. Type 4. 
HLP=Y 
CFG=Y 

DATSTP-P.COM 1.70 5 39 690C DATSTP17 64 08/30/91 Gene Pizzetta 
DATE See DATSTP-U.COM. For Z3PLUS only. 
HLP=Y 
CFG=Y 

DATSTP-U.30M 1.70 3 6 44 EE45 DATSTP17 64 08/30/91 Gene Pizzetta 
DATE See DATSTP-U.COM. Universal version (ZSDOS, ZDDOS and Z3PLUS). 
HLP=Y Type 3 at SOOOh. 
CFG=Y 



tory which do not exist in the second, 
and 3) setting the archive attribute on 
those files which exist in both directo- 
ries, facilitating copying those that do 
not. 

FILT vs 8.0, JUST VS 1 .2 

Gene has reworked several of Irv 
Hoff's text-handling utilities for ZCPR. 
FILT8 is an update to FILT7, Irv's 
widely-used CP/M tool which sets or 
expands tabs and removes several 
types of unwanted characters in ASCI! 
text, WordStar documents, or 
assembler source code files. JUST12 is a 
reworking of Irv's JUSTIFY tool which 
justifies ASCII and WordStar text files 
(see Figure 2 for their syntax). Both 
tools are now command-line driven, 
provide DU and DIR support, error 
flag setting, error handler invocation, 
quiet mode and ZCNFG configuration. 
Under ZSDOS and ZDDOS, both will 
preserve file create date stamps. 

As Gene puts it, the hardest part in 
converting FILT7 and JUSTIFY was 
"deciding how to make the variously 
interactively chosen modes into a 
group of logical command-line 
options." In F1LT8, mode options are 
provided for use with source code (S), 
ASCII text (A), WordStar documents 
"without" dot commands (W), and 
WordStar documents "with" dot 
commands (D). In JUST12, options 
allow for justifying lines starting with a 
space (S), for justifying lines regardless 
of their original length (L), and for 
retaining embedded form feeds. Both 
tools also have a quiet mode option 
(Q). FILT8 and JUST12 are a welcome 
addition to the word-processing/ text- 
handling toolset and, if Gene had not 
intended it so, are also a fitting 
reminder to us all of the legacy of Irv 
Hoff. 

ZTIMEVS1.3 

ZTIME is a new, hardware- 
independent clock utility for setting or 
displaying the date and time under 
ZSDOS or Z3PLUS. See Figure 3 for its 
syntax. 

Date and time entry with ZTIME is 
simplified by a syntax which allows 
missing elements to be filled in from 
the current setting of the clock. Thus, if 
you want to change the hour, say to 
daylight saving time, you need orUy 
type "ZTIME hh:". To adjust the min- 
utes, type "ZTIME :mm", or to set the 
seconds, type "ZTIME ::ss". A unique 
feature of ZTIME is its ability to meas- 
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Figure 1 

CPD Version 1.0 

Usage : 

CPD <dir:Hafn} {dir:} {{/}options} 
Displays files in first directory, marking files 
that axe duplicated in second directory. 
Options : 

B display only files in both directories 

M display only files missing frcm second directory 

A set archive attribute if in both directories 

S Include system files 

P don't page display 

L echo to printer 

F send final form feed 
Options B and M are mutually exclusive. 



Figure 3 

ZTIME Version 1.3 

Displays or sets ZSDOS date and time. 

Usage: 

ZTIME {{mm}/{dd}/{yy}} {{hh} : {mm>:{ss>} 
sets clock, or 

ZTIME <</}option} 
Options : 

C Show date and time continuously 

S Set date and time interactively 

M Store date and time in memory registers 18-23 

E Show elapsed time since using option M 
If no date and time string or option is given, 
the current date and time is displayed. 



Figure 2 

PILT Version 8.0 Copyright (c) 1986 by Irv Hoff 

Usage : 

PILT {dirOinfile {{dir:}outfile} {{/}option8} 
The outfile defaults to the name of the infile. 

Mode Options: 

S Source Code 

A ASCII Text [default] 

W WordStar-remove dot ccnmiands 

D WordStar-retain dot ccmmands 
Other Options: 

T don't use tabs 

Q quiet mode on 



JUSTIFY Version 1.2 Copyright (c) 1988 by Irv Hoff 
Usage: 

JUST {dir:}infile {dir: > {outfile} {{/>options} 
If no outfile is given, default is filetype "JUS". 
In-Text Options, in first column of source file: 

) center this line 

] justify this indented paragraph 

; do not justify this line 

Ccmmand Line Options: 

n line width for justifying (default 65) 
S justify lines starting with apace 
L justify lines regardless of length 
F retain form feeds 
Q quiet mode on 



DATSTP-U.40M 1.70 4 
DATE See DATSTP-U.COM. 
HLP=Y Type 4. 
CFG=Y 



7 52 F6BA DATSTP17 64 08/30/91 Gene Pizzetta 
Universal version (ZSDOS, ZDDOS, or Z3PLUS). 



DATSTP-U.COM 1.70 6 44 A4S0 DATSTP17 64 08/30/91 Gene Pizzetta 
DATE Displays or changes the create and modify date stamps on any file 
HLP=Y from the command line. Universal version (ZSDOS/ZDDOS/ZRDOS with 
CFG=Y DateStamper, under Z3PLUS will display but not change date stamps). 



DATSTP-Z.30M 1.70 3 
DATE See DATSTP-U.COM. 
HLP=Y 
CFG=Y 

DATSTP-Z.40M 1.70 4 
DATE See DATSTP-U.COM. 
HLP=Y 
CFG=Y 

DATSTP-Z.COM 1.70 3 
DATE See DATSTP-U.COM. 
HLP=Y 
CFG=Y 



4 31 3B3E DATSTP17 64 08/30/91 Gene Pizzetta 
For ZSDOS and ZDDOS only. Type 3 at SOOOh. 



5 36 970E DATSTP17 64 08/30/91 Gene Pizzetta 
For ZSDOS and ZDDOS only. Type 4. 



4 31 486D DATSTP17 64 08/30/91 Gene Pizzetta 
For ZSDOS and ZDDOS only. 



DSTATS.COM 1.20 3 V211 2 16 lAOE DSTATS12 19 08/09/91 Terry Hazen 
DISK ZCPR3 disk/user statistics utility. Displays disk block size, disk 
HLP=Y capacity, allocated and free space, list of active user areas, etc. 
CFG=Y Combines DSKMAP and many functions of UMAP. 



10 08/14/91 Bruce Morgen 



EXTEND. 40M 1.40 4 V213 2 11 D4ED EXTEND14 
WP See EXTEND.COM. Type 4. 
HLP=Y 
CFG=N 



EXTEND.COM 1.40 4 V213 1 8 DEOD EXTEND14 10 08/14/91 Bruce Morgen 
WP Text file extender for all Z80 machines. Appends input line to new 
HLP=Y or existing ASCII file. Vs 1.0 (09/81) by Ron Fowler. 
CFG=N 

HELPC.COM 1.50 V213 5 37 5794 HELPC15 24 09/16/91 Howard Goldstein 
HELP Replacement for the standard Z-System HELP utility. Handles crunched 
HLP=N as well as normal, uncompressed help files. Print options are 
CFG=Y disabled when wheel byte is turned off. Configurable with ZCNFG. 



ure elapsed time. An "M" option 
stores the current date and tinie in 
memory registers, and an "E" option 
compares the current time with that 
stored in the registers to calculate the 
elapsed time in hours, minutes and 
seconds (up to 24 hours maximum). 
ZTIME also has an option to show the 
time continuously. Two versions are 
available for ZSDOS and Z3PLUS, 
with wheel byte support (setting the 
clock will not work unless the wheel 
byte is set). 

ZSLIB vs 3.2 

As mentioned last time, Gene has 
released an update (now vs 3.2) of 
ZSLIB, a set of routines which 
provides extensive date and time and 
file stamp support for ZSDOS, 
Z3PLUS and CP/M-Plus (in addition, 
it supplements SYSLIB with a number 
of general-purpose routines). 
Improvements include: greater 
compatibility with DSLIB routines, 
switchable date output in either 
American (mm/dd/yy) or European 
(dd.mm.yy) date order, switchable 
time output in either military (24 hour) 
or civilian format, and more flexible 
command-line parsing of date and 
time specs. Version 3.2 also adds a 
new set of video highlighting routines 
which are much smaller (although 
somewhat slower) than similar 
modules in VLIB4. 
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DATSTPvsl.7 

Gene has also provided some im- 
provements to DATSTP, his utility for 
displaying or changing (from the com- 
mand line) ZSDOS and Z3PLUS create 
and modify date stamps. See Figure 4 
for its syntax. 

DATSTP does not just "replace" 
date and time specs, but "edits" them. 
An editing buffer is loaded with a file's 
current create date stamp and the 
command-line spec is applied to it. 
Any missing fields in the input spec 
remain unchanged in the buffer, 
allowing for very flexible entry. Create 
and modify date stamps can be edited 
individually or both given the same 
stamp. The major changes to DATSTP 
since last October (vs 1.4) are the use of 
ZSLlB32's more flexible parsing of 
date/ time specs and the revival of 
support for DateStamper (DATSTP 
will now function as long as there is a 
!!!TIME&.DAT file on disk; 
DateStamper need not even be 
running). Version 1.7 adds a C option 
which allows use of the current system 
time as the stamp editing source. It 
moves the current date into the edit 
buffer as the default date, but does not 
affect which stamp is modified. You 
must, for instance, use the C and M 
options together to change the modify 
stamp to the current date. 

RC0PYVS1.2 

RCOPY is Gene's tool to automate 
transfer of a set of files to a RAM disk 
at boot-up. As a side benefit, it can re- 
duce considerably the size of 
STARTUP aliases. See Figure 5 for syn- 
tax. 

RCOPY can also be used to copy a 



HELPLSH.COM 1.10 4 V212 3 21 5611 LSHll 66 08/24/91 Rob Friefeld 
HELP Help program for LSH vs 1.1. 
HLP=Y 
CFG=N 

LBREXT.COM 3.30 V213 8 64 159F LBREXT33 35 08/02/91 Howard Goldstein 
LBR Extracts crunched, squeezed and LZH-encoded files from LBRs. 
HT,P-Y Vs 2.0 by Bob Peddicord. 
CFG=y 

LDIR-B.COM 2.20 V211 2 16 A343 LDIRB22 25 09/10/91 Bruce Morgen 
LBR Displays LBR directories showing file dates and sizes. Includes a 
HLP=Y summary line of active/free/deleted/total member entries. For CP/M 
CFG=N 2.2 or CP/Mf with runtime ZCPR3 support. Vs 1.0 (87) by S. Greenberg. 



LHC.COM 
HELP 
HLP=N 
CFG=Y 



2.00 V213 5 40 29F0 LBRHLP20 45 09/16/91 Howard Goldstein 
Remake of HELP 5.3 which reads crunched .HLP files in LBRs. 



LHQ.COM 2.00 V213 5 37 166D LBRHLP20 45 09/16/91 Howard Goldstein 

HELP Remake of HELP 5.3 which reads squeezed .HLP files in LBRs. 
HLP=N 
CFG=Y 

LPUT.COM 2.20 4 V213 6 48 3D8A LPUT22 35 08/26/91 Howard Goldstein 

LBR Automated CPM/ZCPR3 library maker. Does for LBR creation what LGET 

HIiP=Y does for extraction. 
CFG=N 

LSH.30M 1.10 4 V212 8 59 FFE8 LSHll 66 08/24/91 Rob Friefeld 

SHELL Log SHell is a screen-oriented command line editing shell. 

HLP=Y LSHINST.COM installs program defaults and control key bindings. 
CFG=N 



1.10 4 V212 9 
See LSH.3QM. Type 4. 



68 9256 LSHll 



66 08/24/91 Rob Friefeld 



LSH.40M 
SHELL 
HLP=Y 
CFG=N 



LSHF.30M 1.10 3 V212 8 59 17A6 LSHll 66 08/24/91 Rob Friefeld 
SYS See LSH.30M. "Fixed-file", Type-3 version. 
HLP=Y 
CFG=N 

LSHF.40M 1.10 4 V212 9 68 86B3 LSHll 66 08/24/91 Rob Friefeld 
SYS See L5H.30M. "Fixed-file", Type-4 version. 
HLP=Y 
CFG=N 



LSHINST.COM 1.10 4 V212 11 85 6909 LSHll 
SHELL Install program for LSH vs l.Or. 
HLP=Y 
CFG=N 



66 08/2 4/91 Rob Friefeld 



Figure 4 

DATSTP Version U-1.7 (loaded at OlOOh) 
Edits and displays file date stamps under ZSDOS, 
& DateStamper. 



Z3PLUS, 



USAGE : 

DATSTP {dir:}filename {date} {time} {{/}options} 
If no date and time or option is given, date stamps 
are displayed only. Edit and write default to the 
create stamp. 



DATE/TIME FORMAT: 

{mm}/{dd}/{yy} {hh} : {mm} 
{ram}/{dd}/{yy} +{nnnn} 



clock time 
relative time 



OPTIONS: 

C edit the current date and time 

M edit and write the modify stamp 

B write both the create and modify stamps 

Q toggle quiet mode on 

Option C overrides option M for edit. 



figure 5 

RCOPY Version 1.2 

Copies list of files from AO : to AO : 

Usage : 

RC0PY12 {{/} option} 
Option : 

Q toggle quiet mode on 



MOVING? 

Don't leave us behind! 

Send Change of Address six weeks prior to move. 
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list of other types of files from one 
directory to another (e.g., WordStar 
overlay files before a word-processing 
session). The source and destination 
directories and list of files is internally 
configured (with ZCNFG). The file list 
can contain up to 20 files (a limitation 
of ZCNFG; an unlimited number can 
be coded internally). Improvements 
since the last version (9/90) include the 
preservation of date stamps under 
ZSDOS/ZDDOS and the ability to set 
archive, system and/or no-stamp 
attributes on the destination files. 

Program of the Month 
ZCNFG vs 1 .9 (ZSUS Vol 2 #12) 

Remember when you had to edit the 
data options and reassemble the source 
code to configure a program such as 
FileFind to your particular system and 
style of usage? If you were lucky, 
someone provided an overlay patch so 
you didn't have to touch the source 
code itself. Well, much of this is behind 
us now. Al Hawley's universal 
configuration utility, ZCNFG, greatly 
simplifies the configuration of any pro- 
gram. Yes, given that conventions are 
followed in programming of its 
overlay (.CFG) file, any Z-System or 
CP/M program can now benefit from 
its simple, menu-approach to 
cor\figu ration. 

ZCNFG's operation is simple. See 
Figure 6 for ZCNFG's syntax and a 
sample configuration screen. 

The data options and current selec- 
tion for each option are displayed to 
the user in one or more menus. These 
may be in the form of "toggles" for 
yes/no options, multiple-choice op- 
tions, or various edit options (the hex 
or decimal value of a byte, a DU: or 
Z3-style file spec, a printer init string, 
etc.) which the user changes to suit his 
needs. Help screens are usually avail- 
able to explain each configuration op- 
tion. When all options are "set", exiting 
with X or ESC overlays the appropriate 
data to the configuration block in the 
first page of the target program. That 
simple! 

Al has made some major improve- 
ments to ZCNFG since vs 1.6 (7/90). Its 
search logic, for instance, has been 
changed to speed up respoase for com- 
mon types of usage. Now, if either a 
partial or complete DU is given, the al- 
ternate directory is not searched. If the 
CFG name is taken from the target 
file's configuration block, the alternate 
directory is searched first. A colon or 



LT.COM 3.00 CO 7 53 55D6 LT30 56 07/17/91 C. B. Falconer 

LBR Library Type can type normal, LZH-encoded, crunched or squeezed files 

HLP=N whether standalone or in a .LBR. Can extract/uncrunch any/all files 

CFG=N at the same time. Adapted fran Steven Holtzclaw's LUXTYP (06/83). 

NUKEYCLK.COM 0.30 2 16 7FCC NKYCLK03 6 07/13/91 Joe Mortenaen 
lOP Enables lOP Nukey to have current date/time available as macros 
HLP=N within other applications such as WordStar. For ZCPR33+ systems 
CFG=N with built-in clock. 

RC0PY.COM 1.20 3 20 72FD RC0PY12 20 08/17/91 Gene Pizzetta 
FILE Copies a list of files between two directories. 
HLP=Y 
CFG=Y 



3 08/26/88 Bruce Morgen 



STATPAT.Z80 3.00 4 30 0B9A STATPAT3 
PROG4 Patches STAT.COM to work under ZCPR3. 
HLP=Y 
CPG=N 



TPA.COM 3.3a CO 15 EDBB TPA33A 12 08/19/91 Jay Sage 

SYS Reports amount of memory available in TPA (Transient Program Area) 

HLP=N and allows one to temporarily lower the size of TPA. Vs. 3.3 adds 

CFG=N ZCPR "//" help screen, display in kilobytes. 



ZCNFG.COM 1.90 4 V212 6 48 E021 ZCNFG19 109 08/21/91 Al Hawley 
SYS Universal configuration utility which configures option data in 
HLP=Y executable files. Uses .CFG overlay file. 
CFG=Y 



16 08/08/91 Bruce Morgen 



16 08/08/91 Bruce Morgen 



ZCRCK.30M 1.40 3 V211 3 24 806E ZCRCK14 
PILE See ZCRCK.CQM. Type 3 at SOOOh. 
HLP=N 
CFG=N 

ZCRCK.40M 1.40 4 V211 4 29 B3D6 ZCRCK14 
FILE See ZCRCK.COM. Type 4. 
HLP=N 
CFG=N 

ZCRCK.CCW 1.40 3 V211 3 24 2EEA ZCRCX14 16 08/08/91 Bruce Morgen 
FILE ZCPR3-compatible version of Sigi Kluger's NZCRCKl, which was 
HLP=Y designed to combine the features of CRCK and CHEK on RCP/M systems. 
CFG=N Original (05/86) by Bruce Morgen. 

ZDB.COM 1.50 8 64 F4D7 ZDB15 23 09/09/91 Joe Mortensen 

DBASE Small, fast name and address manager with built-in label and 

HLP=Y envelope addressing features. NZTCAP and VLIB4D support. 
CFG=N 

ZDT.COM 1.00 8 64 3034 ZDTIO 43 08/05/91 Joe Mortensen 

DBASE Z-Systsm Day Timer, a daily planning calendar derived from ZDB. 

HLP=N Automatically reads the real-time clock and displays the current 

CFG=N day's schedule. Requires ZCPR3.0+ and extended TCAP. 

ZERR.30M 1.60 3 V212 3 23 DFDA ZERR16 49 08/24/91 Rob Friefeld 
ERROR Bare-bones error handler derived from EASE vs 1.6z. Configured 
HLP=Y with ZERRINST.COM. 
CFG=N 



31 A98A ZERR16 



49 08/24/91 Rob Friefeld 



49 08/24/91 Rob Friefeld 



ZERR.40M 1.60 4 V212 4 
ERROR See ZERR.30M. Type 4. 
HLP=N 
CFG=N 



ZERRINST.COM 1.60 3 V212 4 31 65D1 ZERR16 
ERROR Install program for ZERR.COM vs 1.6. 
HLP=N 
CFG=N 



ZERRLSH.COM 1.10 3 V212 4 29 B69B LSHll 66 08/24/91 Rob Friefeld 

ERROR ZCPR 3.3+ error handler which performs all the functions of ZERR. 

HLP=Y Automatically updates history file, if LSH history shell is active. 
CFG=N Configured with ZERRINST.COM. 



ZERRLSHF.COM 1.10 3 V212 4 29 6719 LSHll 
ERROR See ZERRLSH.COM. "Fixed-file" version. 
HLP=Y 
CFG=N 



66 08/24/91 Rob Friefeld 
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ZFIND.COM 1.40 4 30 B54E ZFIND14 35 08/11/91 Terry Hazen 

FILE ZCPR3 string search utility which very quickly finds ASCII strings in 
HLP=Y text files. Found string can be displayed in either line or delimited 
CFG=Y block. Output can be written or appended to a file. 



X.50 6 47 E427 ZLT15 38 09/12/91 Howard Goldstein 
Z-System Library Typer, basically a Z' if led LT29 with file 



ZLT.COM 
LBR 

HLP=Y extraction and parsing code removed 
CFG=Y Morgen 



ZP.30M 




1.50 3 


8 64 81DA ZP15 


FILE 


See 


ZP.COM. Type 


3 at BOOOh. 


HLP=Y 








CPG=Y 








ZP.40M 




1.50 4 


10 74 FAA2 ZP15 


FILE 


See 


ZP.COM. Type 


4. 


HLP=Y 








CFG=Y 









Vs 1.1 (09/88) by Bruce 



86 08/23/91 Terry Hazen 



86 08/23/91 Terry Hazen 



ZP.COM 1.50 8 64 A257 ZP15 86 08/23/91 Terry Hazen 

FILE ZCPR33+/Z3PLUS/BGii screen-oriented file/disk/memory record patcher 

HLP=Y using the ZPATCH command set. Requires a VLIB4CH- Z3TCAP. One-record 

CFG=Y cache can be exchanged with file/disk/memory records. 

ZSLIBM.REL 3.20 4 27 212 E201 ZSLIB32 94 09/08/91 Gene Pizzetta 
PROGl Assembly language routines to assist programmers in handling date- 
HLP=Y stamp maintenance under ZSDOS, Z3PLUS, and CP/M Plus. Microsoft 
CFG=N REL format. 

ZSLIBS.REL 3.20 4 25 197 412F ZSLIB32 94 09/08/91 Gene Pizzetta 
PROGl See ZSLIBM.REL. SLR format. 
HLP=Y 
CFG=Y 

ZSWEEP.COM 1.30 16 122 C80C ZS13 38 09/11/91 Pete Pardee 

LBR Z'ified version of NSWP207 with ability to act upon current file with 
HLP=N any Z-System command up to 127 chars. NDR support, datestarap display. 
CFG=N Requires ZCPR33+ with extended TCAP. 



ZSWEEPNB.COM 1.20 
LBR See ZSWEEP.COM. 
HLP=N 
CFG=N 



19 152 073A ZS12 49 08/03/91 Pete Pardee 
Generic version (regular TCAP). 



Figure 6 

ZCNFG, Z-SYSTEM CONFIGURATION UTILITY 

Version 1.9, 08/20/91 

Configures option data in Executable files. 
Syntax: 

ZCNFG [du/dir:]<naml>[ .<exl>] [du/dir: ] [<nam2>] [ .<ex2>] 

du/dir: defaults to the current drive and user 

<naml> is the Executable file to configure. 

<nam2> is the configuration overlay file. 

<exl> defaults to COM, <ex2> defaults to CFG 
Example: ZCNFG ZCNFG .-configures itself. 
A related configuration data file must be present to provide 
Screen layout, Menus, and configuration data, 

B0:WORK>zcnfg zcnfg 

ZCNFG, Z-SYSTEM CONFIGURATION UTILITY 
Version 1.9, 08/20/91 



ZCNFG CONFIGURATION 

T) Target Program Default Filetype 
O) Overlay file Default Filetype 
Z) Z3ENV auto-install for ZCPR3 
A) Alternate D/U for Overlay files 
L) console Lines per Screen 
C) Configuration LBR name 



COM 
CFG 

YES 

D15 

24 

CONFIG. LBR 



D) Use TARGET DU as the default for the CFG filespec 

ZCNFG INSTALLATION CONTROL 
X or Esc =Save changes & eXit Q,*C =Quit with no changes saved 
/or 7 =Explain Options > or . =Next Menu < or , "Previous Menu 
Which choice? ^^^^^^^^_^^^_^^^__^_^— ^^— ^— ^ 



form-feed character has also been 
added as the first character of a hne in 
help screens to invoke paging. But that 
isn't all. Back in May, I asked Al if 
ZCNFG couldn't be made to recognize 
its configuration (CFG) files from in- 
side an LBR in a specified directory. 
There were so many of these files lying 
around that they were getting hard to 
keep track of and, for me, were taking 
up a lot of precious hard-disk space. 
Well, with version 1.9, Al has added 
this very feature, giving you the option 
now of allowing them to reside 
unLBR'ed in an alternate directory or 
setting up an LBR of CFGs, with a 
name and location of your choice. 
CONFIG.LBR (the default name of the 
LBR) is expected to be found in 
ZCNFG's alternate directory and is 
now searched first for the CFG file if 
there is no DIR form (D;, U;, DU; or 
DIR:) specified in the invoking com- 
mand tail. 

As Z-Librarian, 1 try to keep an up- 
to-date package of the latest Z-System 
COM files, along with their associated 
HLP and CFG files. Being able to main- 
tain the CFG files in one, single library 
saves considerable time in finding 
needed files and disk space in storing 
them. In September I uploaded to the 
Z-Nodes CFGOl.LBR, a full set of CFG 
files for the latest existing executables 
for use with ZCNFG19. It contained 66 
files (there are now well over 70) and 
took up only 149k, instead of 312k if 
the files were to reside separately on a 
hard disk with 4k-per-file allocation. 

What can I say? ZCNFG has im- 
proved to the point where it is now one 
of the most "essential" of Z-System 
tools. 1 think we can safely say that "Z- 
CoNFiGuration" is the "standard" for 
setting up configuration options for 
users in Z-System programs. It should 
become a standard for CP/M. Many 
thanks. All* 



The ultimate test 
of Man's conscience 

may be in his 

willingness to sacrifice 

something for 

future generations 

whose words of thanks 

will not be heard. 

— Gaylord Nelson 
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Reader, from page 30 

journal has become my favorite computer magazine. 

Please don't forget that some readers are still in the learn- 
ing mode and are not on the same knowledge plane as the 
editor or the authors. I hope that I can feel free to ask some 
dumb questions from time to time and that the journal can be 
a learning tool while still being a method of exchanging ideas 
among peers. 

B.R., Cabot PA 

May I suggest the entire computer elite suffers from a 
common malady. It is not elegant to employ cryptic 
abbreviations and "well-known" mnemonics. The proper 
way to expose is to assume that no reader is an insider but 
that every reader truly desires to understand. 

You should print no article without a complete glossary 
explaining any possibly obscure term. Take a paper you con- 
sider worth publishing. Place it in the hands of someone who 
is decidedly not knowledgeable. Extract from the subject an 
evaluation unencumbered by any form of intimidation or 
put-down by the resident experts. If it ain't right, fbc it. 

I am quite isolated. Have had this Atrix for several years 
and can operate it as an appliance, make simple repairs and 
do a bit of non-elegant BASIC programming. I would very 
much like to upgrade. The machine has an IEEE-48 port, a 
50-pin D-cormector receptacle on the motherboard and the 
ability to address external double sided 5 1/4 and 8-inch 
drives. I would like to add a hard disk or 8-inch floppy. So 
far, I have not found any source of information to help. Ya 
wanna help? 

E.B. Swisshome OR 

True, some readers are not at the level of the authors. In fact, 
no one is at the level of all the authors. TCJ was never meant to be 
light reading. This is a technical journal and authors should not 
oversimplify advanced topics as we frequently cover. Still, I hope 
that our authors note your thoughts and take the extra time to 
explain things. We are all intelligent people here, but we come 
ffom different computer disciplines and need terms defined. 

Please do feel free to ask questions. Most authors give their 
address in their biographical paragraph. Otherwise, ask me and I 
will forward the question on. 

We are promised an article on building a generic SCSI port 
daughterboard. This would allow you to add a hard drive to your 
Atrix. — Ed. 

Thank you for providing a publication for the serious 
hobbyist! 

R.S. Millers MD 

I really appreciate your practical hardware and software 
approach and your Forth coverage. 

I would like see a project of building a very small Z80- 
based portable, even if it requires a separate monitor and 
keyboard, using the super-integrated chips with CTC, DMA, 
SIO and PIO. My idea would be to mount aboard on the side 
of a slim 3.5" floppy drive. Ideally, it would have native 
Forth in ROM that could boot CP/M. 

I am an electronics technician who switched to software 
six and a half years ago. I have been making my living pro- 
gramming in Forth ever since. I would like to work on such a 
project with someone. 

E.]. Portland OR 

This man reads my mind! These were my exact thoughts the 



first time I saw a YASBEC. Anyone for a good hack?— Ed. 



I love it! Could you suggest good back issues for someone 
just starting out in embedded systems? 

G.S., Richmond Height OH 

Take a look at issues 40 onward. I found Tim McDonough's 
articles in 45, 46 and 47 particularly good and continue to hope he 
will submit again. Matt Mercaldo's pieces starting in issue 44 are 
excellent. — Ed. 



1 am so enthusiastic to have found a publication that fits 
my interests that I plan to send a letter detailing just what 
kind of person your newest subscriber is. Is there a method 
of transmitting this letter electronically? This is a "must read" 
publication! 

J.B., Brookshire TX 

Letters and articles can be submitted over the Internet to 
cmcewen@gnat.rent.com, on GEnie at TCJ$ or on my bulletin 
board at (908) 754-9067. The Internet address is courtesy of Andy 
Meyer. The GEnie address goes to all the TCJ editors, so don't 
give away state secrets! Don't be shy about submitting an idea for 
an article, either. — Ed. 



I believe a simple mistake has been made in relation to my 
subscription. The renewal notice states that my subscription 
expires with issue 54. It should expire six issues later as 1 
subscribed for two years. 

P.C, Balcatta WA Australia 

Oops! My mistake. This happens now and then. Did you notice 
that the address label shows your expiration? Let me know if it 
isn't right. All I need is a note to look into it.— Ed. 



One small note of editorial concern: In issue 52, Richard 
Rodman's column gets to the bottom of page 49, then 
launches out into hyperspace, never to appear again in the 
magazine. 

B. M., Gainesville FL 

Your electronic mail was my first clue of this mistake. It was 
the first of a flood, and I learned my lesson: Never mess with 
Richard's column! — Ed. 

I wanted you to know that I am impressed with TCJ's 
content! It is by far the most bang-for-the-buck I've seen in 
ten years in the magazine industry. 

P.T., West Lafayette IN 

Thanks! Glad you're enjoying it. 



1 own a CP/M computer named "Alphatronic PC" here in 
Germany and "Royal Alphatronic" in the UK. It was never 
intended to add a hard disk to this machine, which I would 
like to do. I read that there exists a kind of SCSI card for 
systems like mine that one needs only to remove the Z80 
chip, then plug in that board and then put in the Z80 chip in 
that board. Do you know where in the States I can order such 
a board, preferably with an appropriate hard disk and the 
software? I have the BIOS for my system, so software is not 
the problem. Were there some articles in former TCJ issues 
describing how to add a hard disk to systems like mine? 

U. N., Bonn, Germany 

Check Wayne Sung's article in issue 40 on adding a Bernoulli 
drive. He tells how to adapt the parallel port to a generic SCSI. 
Also, George Warner has been saying he will write an article about 
this.— Ed. 
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CP/M SOFTWARE 

100 page Public Domain Catalog, 
$8.50 plus $1.50 shipping and hand- 
ling. New Digital Research CP/M 
2.2 manual, $19.95 plus $3.00 
shipping and handling. Also, MS/ 
PC-DOS Software. Disk Copying, 
including AMSTRAD. Send self 
addressed, stamped envelope for free 
Flyer, Catalog $1.00 

Elliam Associates 

Box 2664 

Atascadero, CA 93423 

805-466-8440 



Advent Kaypro Upgrades 



TurboROM. Allows flexible conflgura- 
tion of your entire system, read/write 
additional formats and more. $35 

Hard drive conversion kit. Includes 
interface, controller, TurboROM, soft- 
ware and manual — Everything needed 
to install a hard drive except the cable 
and drive! $175 without clock, $200 
with clock. 

Personality Decoder Board. Run more 
than two drives, use quad density 
drives when used with TurboROM. $25 

Limited Stock — Subject to prior sale 
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First Insertion: 
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$50 
$35 



Rates include typesetting. Payment must accom- 
pany order. Foreign orders paid In US funds 
drawn on a US bank or International money order. 
Resetting of ad constitutes a new advertisement 
at first insertion rate. Camera ready copy from 
laser printers, photo typesetters, etc., are accept- 
able. Dot matrix, daisy wheel, typewriter output 
not accepted. Inquire for rates for larger ads If 
required. Deadline is eight weeks prior to publi- 
cation date, Mail to: 

The Computer Journal 

Maricet Place 

PO Box 12 

S. Plainfield NJ 07080-0012 USA 



Z"System Software Update Service 

Provides Z-System public domain software by mail. 

Regular Subscription Service 

Z3C0M Package of over 1 .5 MB of COM files 

Z3HELP Package with over 1 .3 MB of online docunfientation 

Z-SUS Programmers Pack, 8 disks full 

Z-SUS Word Processing Toolkit 

And More! 

For catalog on disk, send $2.00 ($4.00 outside North America) 
and your computer format to: 

Sage Microsystems East 

1435 Centre Street 



Editor, from page 26 

many letters as we have room for. The 
authors also welcome your comments. 
What is missing may be more 
important than what is here! Time just 
ran out and I had to bump some very 
promising articles to the next issue. 
Bridger Mitchell retunis to discuss I/O 
Redirection. David Goodenough will be 
here to discuss Interrupts and the Z80, 
while Brian Moore will tell us how to 
install ZCPR on a 16-bit Intel Platform. 
George Warner tells us how to double 
the clock speed on an Ampro. We have 
a good article on cyclical redundancy 
checking in Forth, and 1 expect more 
on the system software for the 
YASBEC. Stay tuned!* 



I am one of the REH CPU280 users and love it. It's fast 
and the operating system Tilman built with the automatic 
changing of formats is better than Uniform. It's great for a 
member of a club who often has to change formats for send 
software disks to members. 

We have a OMTI 55xx card working with the CPU280 and 
1 use a 68MB RLL Toshiba HD. Tilman built a AT-BUS 
adapter card and Uwe Herzceg made the BIOS for the AT- 
BUS hard disk. It will work together with my CPU280 and 1 
hope 1 have the time doing the same with my GENIE Ills. 

I am collecting old CP/M computers and have a Genie 1, 
III, Ills, a Kaypro II, an Epson Px-8, a REH CPU280, a Mor- 
row MD3, a Sharp 3541, a Tatung TPC-2000. The C128 is for 
the only PROM burner I have. 

If someone has a Genie III or Ills or a Speedmaster I can 
send him the opcode of the BIOS (OS) CP/M 2.2 and 3. 



Maybe that these nice computers found the way to the USA. 

I want to get all the old TCJs. What would it cost and can 
I get them? 

F.C., Saarstr. Germany 

Your computer room has more inventory than most stores over 
here! To the best of my knowledge, some of your machines never 
made it to these shores. You must have your work cut out for you 
in supporting your users with disks. I know what I go through for 
ZSUS! 

Your group is likely the most active in the world, and you 
surely have some high powered help. I look forward to hearing 
more about what everyone is up to. 

Take a look on pages 46 and 47 for a listing of the available back 
issues. Some are sold out, others nearly so. Still, there are enough 
issues still available to make it through a cold long winter. — Ed.% 
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• ZCPR3 Corner: Z-Nodes, Z-Plan. 
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• The Computer Corner. 
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The Computer Comer 



By Bill Kibier 



It was a busy summer and not just with outside activities. 
The computer industry seems to have been on double shift 
these days. The number of new items seems to belie any 
signs of there being a recession. So lets talk about two new 
items to play with. 

DOS 5.00 

By the time you read this, I doubt any of you will not have 
tried or installed the new DOS 5.00. I have mine and have 
been doing some playing with it. First off let me say it 
appears to work correctly and as advertised. For Microsoft 
that is a new step up. Not only are they usually very late 
with their product releases but they have a tendency to fall 
somewhat short of expectations. 

The expectations of DOS 5.00 however have never been 
too great, so if it does what you want, then it must be OK. In 
reviewing some of the programs I can see that for the most 
part the new features are those public domain utilities which 
everyone used to make up for DOS's shortcomings. An ex- 
ample is DOSKEY which stores keystrokes for later recalling 
and editing. I know lots of people who have been using simi- 
lar programs like that for years. 

So what does this new version give you to make it worth 
all the hoopla, relocatable drivers. Beside working without 
bugs (at least so far) the ability to put DOS and their drivers 
into extended memory is probably the most important 
change. We use LAN based programs and the LAN drivers 
had our program memory space down to 340K. Several pro- 
grams have trouble working in that space, but with DOS 5.00 
I have been able to get 478K of program space. It is still not 
what I really need and any 68K based computer would not 
have these problems, but for DOS it is a great step forward. 

It took some time of playing around with the extended 
memory drivers before I got the extra memory. It may be 
possible to get more but it took half a day to get that. The 
book is fair for support. They have tried to explain things in 
term for all levels of lasers. Unfortunately the drivers section 
is a complex issue and so much variability exists in user 
systems that I am not sure it can be explained properly any- 
where. Microsoft's attempt is good but falls short. I think it 
needs a more cook book approach with some complete and 
typical examples. As it is, the instructions are broken into 
many small sections and the overall relationships between 
the parts is lost. 

After a few hours of trying different options I believe I 
understand the relationships between the parts. It appears 
that the drivers can go only into what I call the shadow 
memory behind the ROMS and video ram. That means maxi- 
mum of 340K of RAM less system and other special block or 
in my case 140K of upper memory. And yes there are all 



kinds of new terms bantered around. UMB got used every- 
where and is defined as Upper Memory Block, but how it is 
really used is left out. 

1 guess my only complaint is the absence of a real expla- 
nation for how it works internally, and thus how you can 
beat or overcome their limits if your case doesn't fit one of 
their normal options. The overall report however is good and 
I reserve the right to change my mind about it as time goes 



Time Moves On 

Well I have spent some time working with MINIX and 
reached some stumbling blocks. It is not so much actual 
problems as it is philosophical ones. I have gotten lazy in my 
latter years and a two year old boy eats up what little time 
remains. When starting on MINIX I discovered just how 
many learning steps were involved. The question is do I want 
to know about all these new items. 

Those items range from editors, to assemblers, make files 
to linking scripts. The number of steps to put together a 
working system is mountainous. What it has boiled down to 
is do I want to become a UNIX-like guru or do I want a 
simple operating system that can be ported easily between 
platforms. 

Currently I am still mulling over the dilemma and would 
tend to lean toward the small C operating system. I used a 
commercial industrial controller based on it and found it 
adequate. The whole code fits on a 360K floppy without zip- 
ping. Compare that to MINIX and the multiple sections of 
code, many disks of compressed files, complex assembling 
and linking, and dozens of new utilities. The small C operat- 
ing system uses C based utilities to give it a DOS like feel. 

DOS has made me lazy over the years and I have found 
their utilities rather user friendly, simple, and straight for- 
ward. MINIX utilities at present for me are complex, cryptic, 
and hard to use. 1 know if 1 spend many hours playing with 
MINIX I will probably find the tools they have more power- 
ful and in time easier to use. For now however I am not sure 
I have the time or desire to learn them. I am finding this fact 
even with DOS 5.00 that many of their new utilities are better 
and more helpful and yet I am not sure I will learn their full 
use if any use at all. I often remark on how CP/M did every- 
thing I needed for many years, so why do I need more com- 
plexity in my life now? 

Make It Simple 

I took a refresher course the other day on Aldus Page- 
Maker 4.0 and had a wonderful time. We put together a 
simple one page newsletter in three hours that included a 

See Computer Comer, page 37 
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Get It To Market--FAST 
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No Source! 

A minor glitch has shown up In the firmware, and you can't find the original 
source program. Our line of diaaasemblers carl help you rB-oreate the 
original assembly language source. 

Set To Go 

Buy our developer package and the next time your laoss says "Get to work,", 
you'll be ready for anything. 

Quality Solutions 

PseudoCorp has been providing quality solutions for rriieroproeessor 
problems since 1965. 

BROAD RANGE OF SUPPORT 

• Currently we support the following mloroprooessor families (with 
more In development); 

Intel 8048 RCA 1802,06 

Motorola 6800 Motorola 6801 :;».-,*-.« a. 
Hitachi 6301 Motorola 6809 MOS Tech 6502 

Rockwell 65C02 Intel 8060,85 Zilog ZSO 

Hitachi HD64180 Motorola too,8 Motorola 68010 

• All products require an IBM PC or compatible 

So What Are You Waiting For? Call us: 

PseudoCorp 

Professional Development Pwdueis Group 

716 Tliimt'le Shoals BW, Suite !•: 

Newport News, VA 23606 
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Custom Software Solutions for Industry: 
Industrial Controls 
Operating Systems 
Image Processing 
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Order Entry 
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SAGE MICROSYSTEMS EAST 

Selling Sz Supporting the Best in 8-Bit Software 

• Automatic, Dynamic, Universal Z-Systems: Z3PLUS for CP/M-Plus computers, 
NZCOM for CP/M-2.2 computers ($70 each) 

• XBIOS: the banked-BIOS Z-System for SB 180 computers at a new, lower price ($50) 

• PCED — the closest thing to Z-System ARUNZ, and LSH under MS-DOS ($50) 

• DSD: Dynamic Screen Debugger, the fabulous full-screen debugger and simulator, 
at an incredible new price, down from $130 ($50) 

• ZSUS: Z-System Software Update Service, public-domain software distribution service 
(write for a flyer with full information) 

• Plu*Perfect Systems 

- Backgrounder ii: CP/M-2.2 multitasker ($75) 

- ZSDOS/ZDDOS: date-stamping DOS ($75, $60 for ZRDOS owners, $10 for 
Programmer's Manual) 

- DosDisk: MS-DOS disk-format emulator, supports subdirectories and 
date stamps ($30 standard, $35 XBIOS BSX, $45 kit) 

- JetFind: super fast, extemely flexible regular-expression text file scanner ($50) 

• ZMATE: macro text editor and customizable wordprocessor ($50) 

• BDS C - including special Z-System version ($90) 

• Turbo Pascal — with new loose-leaf manual ($60) 

• ZMAC — Al Hawley's Z-System macro assembler with linker and librarian 
($50 with documentation on disk, $70 with printed manual) 

• SLR Systems (The Ultimate Assembly Language Tools) 

- Z80 assemblers using Zilog (Z8GASM), Hitachi (SLR180), or Intel (SLRMAC) 
mnemonics, and general-purpose linker SLRNK 

- TPA-based ($50 each tool) or v-itual-memory ($160 each tool) 

• NightOwl (advanced telecommunications, CP/M and MS-DOS versions) 

- MEX-Plus: automated modem operation with scripts ($60) 

- MEX-Pack: remote operation, terminal emulation ($100) 

Next-day shipping of most products with modem download and support available. Order 
by phone, mail, or modem. Shipping and handling $3 per order (USA). Check, VISA, or 
MasterCard. Specify exact disk format. 

Sage Microsystems East 

1435 Centre St., Newton Centre, MA 02159-2469 

Voice: 617-965-3552 (9:00am- 11:30pm) 

Modem: 617-965-7259 (pw^DDT) (MABOS on PC-Pursuit) 



